Salesforce Developer Intern

Sign up for a free Salesforce Developer Edition org, which includes the Developer Console and full Apex access at no cost.

Confirm you can open the Developer Console and execute anonymous Apex.

Start with the language rather than the platform.

Write Apex in the Developer Console demonstrating variables and data types, collections covering List, Set, and Map, loops, conditionals, and a method that accepts parameters and returns a value.

Run each in Execute Anonymous and capture the debug output.

Now work with records in code.

Write Apex that queries records with SOQL, iterates the results, and inserts, updates, and deletes records through DML.

Deliberately write one query returning no rows and handle that case, because code assuming data exists is the most common beginner failure.

Next, meet the platform limits.

Research governor limits and write a short explanation of why they exist on a shared platform.

Then write a query inside a loop, observe the problem, and rewrite it correctly so the query sits outside the loop.

Capture both versions and explain the difference in queries consumed.

Finally, write a note on when Apex is the wrong choice, listing three requirements you could meet with configuration instead, since a developer who reaches for code first creates maintenance nobody else can support.

Submit your Apex samples with debug output, the records exercise, the before-and-after bulkification comparison, and the restraint note.

Define a requirement that touches related records, such as rolling a total from child records onto a parent, or stamping a field when related records reach a condition.

First try to meet it without code.

Attempt a roll-up summary field or a Flow, and document what you built.

Then establish precisely where the declarative approach falls short, for example a roll-up that lookup relationships do not support or logic Flow cannot express cleanly.

This written justification is the gate before any code.

Now write the Apex trigger.

Keep logic out of the trigger body and in a handler class, which is the pattern teams expect.

Make it bulk safe by processing collections rather than single records, and avoid queries inside loops.

Write unit tests properly.

Create your own test data inside the test class rather than relying on org records, and cover the single record case, the bulk case with at least two hundred records, and the negative case where the trigger should do nothing.

Confirm coverage above seventy five percent and screenshot the result.

Then break it deliberately.

Write a test proving what happens when a required related record is missing, and handle that case in code rather than letting it throw.

Submit the declarative attempt with its documented limitation, the trigger and handler class, the full test class, the coverage screenshot, and a note on what your trigger does not handle.

Define a small user-facing need a standard page cannot meet well, such as a focused search over custom records or an entry form combining fields from two objects.

Build a Lightning Web Component for it using the Developer Console or local tooling, both free.

Create the HTML template, the JavaScript controller, and the metadata configuration, and deploy it to a Lightning record or app page in your own org.

Connect it to data.

Use a wire adapter or an Apex method marked cacheable to fetch records, and render them.

Then add the ability to create or update a record from the component and confirm the change persists.

Now handle the states beginners omit.

Your component must behave correctly while data is loading, when the query returns nothing, and when the server call fails.

Force each state deliberately and screenshot the result, because a component that only works on the happy path is not finished.

Test it as a restricted user.

Use Login As with a profile lacking access to the underlying object and record what the component does, then handle that case so it fails with a clear message rather than a blank panel.

Submit the component source, deployment screenshots, evidence of all three states, the restricted user test, and a note on what you would change to make it reusable elsewhere.

Some work cannot run in the user's transaction, and knowing which pattern to use is a core developer judgement.

Research the asynchronous options available in Apex covering future methods, Queueable, Batch Apex, and Scheduled Apex, and write a short comparison stating what each is for and the situation where each is the right choice.

Now build one.

Create a requirement needing to process more records than a single transaction allows, such as recalculating a field across thousands of records, then implement it with Batch Apex.

Generate enough test data in your own org to make the batching real, run the job, and capture the result from the Apex Jobs page.

Then schedule it.

Make the job run on a schedule and record how you would verify it ran successfully when nobody is watching.

Next, review your own work.

Write a short code standard covering naming, where logic belongs, error handling, and test data creation.

Then review the trigger and component you built in earlier tasks against that standard and list every place your own code falls short.

Fix at least three of the issues you found and show the before and after.

Submit the async comparison, the batch class with job evidence, the schedule setup, your code standard, the self review findings, and the three fixes.