Developer Console is split into seven loosely defined workspaces. Each one corresponds to a distinct developer task.
The seven tasks
1. Edit and save Apex code
Classes, triggers, Visualforce, and Aura components are full-fidelity — you can create, edit, save, delete. LWC is read-only: you can browse it, but you cannot create or modify LWC in Developer Console (that requires VS Code or the metadata API).
File → New → Apex Class
File → Open → Apex Trigger → AccountTrigger2. Execute Anonymous Apex
The killer feature. Open Debug → Open Execute Anonymous Window (Ctrl+E), type code, run it. No class to save, no test to write.
List<Account> a = [SELECT Id FROM Account LIMIT 10];
System.debug('Found ' + a.size() + ' accounts');Useful for: quick data inspection, one-off fixes (update), prototyping logic before committing it to a class.
3. Run SOQL and SOSL queries
The Query Editor tab. Toggle “Use Tooling API” to read setup objects (ApexClass, ApexTrigger, FlowDefinition, etc.). Results appear in a grid you can sort, edit inline, and write back to the database with Save Rows.
4. View and analyze debug logs
The Logs tab shows every recently captured log for the user, filtered by name, time, status, and size. Double-click one to open the Log Inspector — Source, Stack, Variables, Execution Tree, Limits, all from a single log file.
5. Run Apex tests and inspect coverage
The Tests tab launches one test, one class, or all tests. Coverage shows as green/red gutters in the Apex editor — every covered line green, every uncovered line red. The Overall Code Coverage panel shows org-wide percentage and per-class breakdown.
6. Open and inspect metadata
File → Open and File → Open Resource (Ctrl+Shift+O) reach almost any metadata in the org — pages, classes, components, even custom labels. Read-only for some types but discoverable for all.
7. Use the Checkpoints feature
Set a checkpoint on a line of Apex (similar to a breakpoint in a traditional debugger). The next time that line executes, the platform captures a deep dump of variables, heap, and SOQL state. You then open Debug → View Checkpoints to inspect the dump. Faster than recompiling with System.debug everywhere.
What it explicitly cannot do
| Task | Why not |
|---|---|
| Edit LWC | LWC is bundle-based; Developer Console’s metadata model doesn’t support it |
| Manage Permission Sets / Profiles | Setup-only |
| Deploy between orgs | No source-control / change-set concept |
| Run JavaScript-side LWC tests (Jest) | Requires a Node toolchain |
| Bulk metadata operations | Use SFDX / sf CLI |
| Source diffs | No SCM |
A quick reference table
| Task | Developer Console tab / shortcut |
|---|---|
| New Apex class | File → New → Apex Class |
| Execute anonymous Apex | Ctrl+E |
| Run a SOQL query | Query Editor |
| Open a recent debug log | Logs tab → double-click |
| Run all tests | Test → New Run → Select Tests → Run |
| Set a checkpoint | Click in the left gutter of an Apex file |
| Inspect heap dump | Debug → View Checkpoints |
What interviewers are really looking for
Reciting “edit Apex, run anonymous code, view logs” earns a pass. Standout answers add: (1) Developer Console cannot edit LWC, (2) the Log Inspector is the killer debugging surface — Source, Limits, Stack Tree, (3) Checkpoints are a real-debugger-style alternative to scattering System.debug, (4) Tests run with inline coverage gutters, (5) the Tooling API toggle in Query Editor exposes setup metadata.
Verified against: Salesforce Help — Developer Console Tabs and Workspaces. Last reviewed 2026-05-17.