Salesforce Developer
The 30-Day Sprint

"Future vs Queueable" is the single most-asked developer question set in Salesforce interviews. Today you earn the right to answer it with opinions.

• TheoryWhy async exists + @future mechanics1.25h
  Open theory — the three reasons, and future's rules

  Why go async at all (give all three in interviews)

  • Callouts: triggers can't call external APIs synchronously — hand off to async.
  • Higher limits: async transactions get 200 SOQL, 12MB heap, 60s CPU.
  • Mixed DML: setup objects (User…) and normal records in one flow → split one side into async.

  @future rules

  • Static, void, primitive parameters only (no sObjects — records could be stale by run time; pass Ids and re-query).
  • @future(callout=true) to allow callouts.
  • No chaining (future can't call future), no job object handle returned, 50 per transaction.
  • Enqueued work starts only after the transaction commits — rollback = never ran. No guaranteed order.

  public class UserProvisioner {
      @future
      public static void createUser(String alias, String email) {
          insert new User(Alias = alias, Email = email, /* ... */
              ProfileId = [SELECT Id FROM Profile WHERE Name='Standard User'].Id,
              Username = email, LastName = alias,
              EmailEncodingKey='UTF-8', LanguageLocaleKey='en_US',
              LocaleSidKey='en_US', TimeZoneSidKey='Asia/Kolkata');
      }
  }

• TheoryQueueable — the modern default (+ Transaction Finalizers)1.5h
  Open theory — interface, chaining, finalizers, when-which

  • Implements Queueable (+ Database.AllowsCallouts for callouts). Instance class → complex state: pass sObjects, lists, anything via constructor.
  • Id jobId = System.enqueueJob(new KycCheckJob(ids)); returns an Id → monitor via AsyncApexJob (Status, NumberOfErrors) or Setup → Apex Jobs.
  • Chaining: inside execute() you may enqueue one child job. Unlimited depth in prod; capped at 5 in Developer/Trial orgs. In tests, chaining throws — guard with if (!Test.isRunningTest()).
  • Transaction Finalizers: System.attachFinalizer(this) with a class implementing Finalizer — its execute(FinalizerContext ctx) runs even if the queueable died on an uncatchable limit error. ctx.getResult() tells success/failure → retry or log. Mentioning finalizers = instant senior signal.

  public class KycCheckJob implements Queueable, Database.AllowsCallouts, Finalizer {
      private List<Id> accountIds;
      public KycCheckJob(List<Id> accountIds) { this.accountIds = accountIds; }
  
      public void execute(QueueableContext ctx) {
          System.attachFinalizer(this);
          // callout + DML here ...
          if (needsSecondPass && !Test.isRunningTest()) {
              System.enqueueJob(new KycCheckJob(remainingIds)); // one child max
          }
      }
      public void execute(FinalizerContext fc) {
          if (fc.getResult() == ParentJobResult.UNHANDLED_EXCEPTION) {
              ErrorLogger.log(fc.getException(), 'KycCheckJob', 'execute', null);
          }
      }
  }

  When which (the answer table lives in Reference → Async comparison)

  • Rule of thumb: Queueable is the default; @future only for trivial fire-and-forget/mixed-DML; Batch for >50k rows; Schedulable for timing.
• BuildF1 mixed-DML demo + Q1 chained queueable + tests3h
  Spec

  1. F1: script that inserts an Account AND a User in one transaction → capture the MIXED_DML error text; then fix via the @future UserProvisioner. Keep both versions in the repo with a comment explaining.
  2. Q1: AccountEnrichmentJob (Queueable): takes List<Id>, sets Enriched__c=true + timestamp, then chains EnrichmentLogJob writing a summary row to Error_Log__c (Severity=Info). Finalizer logs failures.
  3. Tests: Test.startTest(); System.enqueueJob(...); Test.stopTest(); then assert the field changes. Assert job ran via [SELECT Status FROM AsyncApexJob WHERE Id = :jobId]. Remember the chain-guard for tests.

  Done when: tests green; you've watched the jobs in Setup → Apex Jobs; you can say why Q1 couldn't be @future (complex params, chaining, monitoring).

• TrailheadAsynchronous Apex — future + queueable units45m
• DrillAnswer aloud — 5 questions30m
  Questions + key points

  • future vs Queueable — full comparison. (params, chaining, job Id, monitoring, when each — the headline answer of the week)
  • Why no sObject params in @future? (serialization + staleness; pass Ids)
  • How do you chain jobs and what are the limits? (1 child per execute; dev-org depth 5; test guard)
  • What is a Transaction Finalizer? (post-mortem hook, runs even on limit death, retry pattern)
  • When does async work actually start? (after commit; order not guaranteed)
• Comm3 × 2-min explainers45m
  ① the three reasons async exists ② future vs Queueable ③ your Q1 design with finalizer.

Millions of rows, nightly jobs, CRON strings — the "enterprise" half of async. Your Dormant Account Flagger built today goes straight into the capstone.

• TheoryBatch Apex — start / execute / finish1.5h
  Open theory — the interface, statefulness, monitoring

  public class DormantAccountBatch implements
          Database.Batchable<SObject>, Database.Stateful {
      private Integer flagged = 0;
  
      public Database.QueryLocator start(Database.BatchableContext bc) {
          return Database.getQueryLocator([
              SELECT Id FROM Account
              WHERE LastActivityDate < :Date.today().addDays(-180)
                AND Status__c != 'Dormant']);
      }
      public void execute(Database.BatchableContext bc, List<Account> scope) {
          for (Account a : scope) { a.Status__c = 'Dormant'; }
          update scope;
          flagged += scope.size();
      }
      public void finish(Database.BatchableContext bc) {
          System.debug('Flagged: ' + flagged);
          // email summary, or chain the next job here
      }
  }
  // run: Database.executeBatch(new DormantAccountBatch(), 200);

  • start returns a QueryLocator (up to 50M rows) or an Iterable (custom lists, but 50k limit applies).
  • execute runs per chunk — default scope 200, settable up to 2,000 via executeBatch(job, scope). Each execute = fresh governor limits; one chunk failing doesn't stop the others.
  • Database.Stateful preserves instance fields across executes (counters, error lists) — without it every chunk starts clean. Costs serialization time; use only when needed.
  • finish runs once at the end — summary email, chaining the next batch, enqueueing a queueable.
  • Limits: 5 concurrent batch jobs; 100 more can wait in the flex queue. Monitor: AsyncApexJob / Setup → Apex Jobs. Callouts: implement Database.AllowsCallouts; scope size × callouts-per-record must stay under 100 per execute — a real interview scenario ("how would you size scope for a callout batch?").
• TheorySchedulable + CRON1h
  Open theory — scheduling, CRON format, the thin-shell rule

  public class NightlyDormantSweep implements Schedulable {
      public void execute(SchedulableContext sc) {
          Database.executeBatch(new DormantAccountBatch(), 200); // thin shell
      }
  }
  // 2:00 AM every day:
  System.schedule('Dormant sweep', '0 0 2 * * ?', new NightlyDormantSweep());

  • CRON fields: Seconds Minutes Hours Day-of-month Month Day-of-week [Year]. Examples: '0 0 2 * * ?' daily 2am · '0 30 18 ? * MON-FRI' weekdays 18:30 · '0 0 8 1 * ?' 1st of month 8am.
  • Thin-shell rule: keep logic out of the Schedulable — the scheduled class version gets pinned, complicating deploys; it should only launch a batch/queueable.
  • Manage: Setup → Scheduled Jobs; System.abortJob(cronTriggerId); query CronTrigger. Max 100 scheduled jobs.
  • Alternative worth name-dropping: Scheduled Flows for declarative nightly work; and scheduled batch via the UI (Apex Classes → Schedule Apex).
• BuildB1 — Dormant Account Flagger (batch + schedule + tests)3h
  Spec

  1. Create Status__c picklist on Account (Active/Dormant) if not present.
  2. Batch per the skeleton, but: Stateful counters for flagged + skipped; collect failures with Database.update(scope,false) + ErrorLogger; finish() sends a summary email via Messaging.SingleEmailMessage to yourself.
  3. Schedulable thin shell + schedule it for 2 AM; verify it appears in Scheduled Jobs.
  4. Tests: seed old-date accounts (careful — LastActivityDate isn't writeable; filter on a custom Last_Touch__c Date field you control instead. Note this in README: test-data-friendly design is a real skill), Test.startTest(); Database.executeBatch(...); Test.stopTest(); assert statuses + counter via a public @TestVisible field. Test the Schedulable with System.schedule in-test + assert CronTrigger exists.

  Done when: green tests incl. batch + schedulable; summary email arrives in your inbox from a real run.

• TrailheadAsynchronous Apex — finish the badge45m
• DrillAnswer aloud — 6 questions30m
  Questions + key points

  • Walk through Batchable's three methods. (roles + limits reset per execute)
  • QueryLocator vs Iterable? (50M vs 50k; when custom iteration)
  • What does Database.Stateful do? (fields survive across executes; serialization cost)
  • Write the CRON for weekdays 6:30 pm. ('0 30 18 ? * MON-FRI')
  • How do you size batch scope for callouts? (≤100 callouts per execute → scope accordingly)
  • All four async types — one-line when-to-use each. (the Reference table, from memory)
• Comm3 × 2-min explainers45m
  ① batch lifecycle ② Stateful with your counter example ③ the four async types speed-round.

Two launches: your first real API integration, and your candidacy. From today, 45 minutes of job-hunt work is a daily non-negotiable.

• TheoryCallout mechanics50m
  Open theory — Http classes + the rules

  HttpRequest req = new HttpRequest();
  req.setEndpoint('callout:Exchange_API/v6/latest/USD'); // Named Credential merge
  req.setMethod('GET');
  req.setTimeout(20000);                                  // ms, max 120000
  HttpResponse res = new Http().send(req);
  if (res.getStatusCode() == 200) {
      Map<String, Object> body =
          (Map<String, Object>) JSON.deserializeUntyped(res.getBody());
  }

  • Limits: 100 callouts/transaction; cumulative timeout 120s.
  • No callout after DML in the same transaction — "uncommitted work pending." Order: callout first, DML after — or split into async.
  • Triggers → never call out synchronously; enqueue a Queueable with AllowsCallouts.
  • Design words that impress: idempotency (safe retries — pair with upsert + External Id), retry with backoff (finalizer or scheduled re-run), timeout budgets.
• TheoryNamed Credentials & OAuth in one page40m
  Open theory — where secrets live, how auth flows work

  • Named Credential = endpoint + auth config stored by the platform; code says callout:My_NC/path and never touches secrets. Modern setup splits External Credential (the auth: OAuth/JWT/Basic + principals) from the Named Credential (the URL). Legacy NCs bundle both — recognize either in an org.
  • Why it matters in interviews: "no hardcoded endpoints or passwords; rotation without deploys; per-user vs named-principal identity" — say exactly that.
  • Raw endpoint without NC → requires Remote Site Setting (the older allowlist).
  • OAuth flows, one line each (for "how does the external system authenticate?"): Authorization Code = a human logs in (web apps). Client Credentials = server-to-server with client id/secret. JWT Bearer = server-to-server with a certificate, no user interaction — the classic choice for middleware → Salesforce. Inbound callers hit a Connected App to get a token, then call your API with Authorization: Bearer ….
• TheoryJSON in Apex — typed & untyped50m
  Open theory — wrappers, deserialization, the reserved-word trick

  // Typed — define a wrapper mirroring the payload
  public class RatePayload {
      public String base_code;
      public Map<String, Decimal> conversion_rates;
  }
  RatePayload p = (RatePayload) JSON.deserialize(res.getBody(), RatePayload.class);
  Decimal inr = p.conversion_rates.get('INR');
  
  // Untyped — spelunking with casts
  Map<String, Object> root =
      (Map<String, Object>) JSON.deserializeUntyped(res.getBody());
  Map<String, Object> rates = (Map<String, Object>) root.get('conversion_rates');
  Decimal inr2 = (Decimal) rates.get('INR');

  • Typed = compile-safe, testable — default for stable APIs. Untyped = flexible for ragged payloads.
  • JSON key is an Apex reserved word (currency, case)? Wrapper can't declare it — either pre-process body.replace('"currency":', '"currency_x":') or read that field untyped.
  • JSON.serialize(obj) for outbound; JSON.serializePretty for debugging. Tools: JSON2Apex generates wrappers from a sample payload.
• BuildC1 — Exchange-rate service (Named Credential + wrapper + storage)2.5h
  Spec

  1. Pick a free, keyless API — https://open.er-api.com/v6/latest/USD works. Create the Named Credential (anonymous auth) → name it Exchange_API.
  2. Design for testability: interface RateProvider { RatePayload fetch(String base); } + HttpRateProvider implementation. ExchangeRateService.refresh('USD') calls the provider, upserts Exchange_Rate__c rows (fields: Base__c, Target__c, Rate__c, unique External Id Pair_Key__c = "USD-INR") — your upsert + External Id story, live.
  3. Failures → ErrorLogger. Run from anonymous; verify rows.

  Done when: rates in the org, re-running updates instead of duplicating (External Id proof), zero hardcoded URLs.

• Job huntLAUNCH — resume, profiles, tracker, first 10 applications2h
  Templates: Reference → Scripts & templates. From tomorrow this is a daily 45m task.
  Launch checklist

  1. Resume (1 page): headline "Salesforce Developer — Apex · LWC · Integrations · Sales/Service Cloud · FSC (learning) · PD1 (scheduled)". Projects section with GitHub links + 3 bullets each using the formula in Reference. Honest experience section — your real background, framed toward Salesforce.
  2. LinkedIn: same headline; About = 4 lines (who, stack, proof links, what you're looking for); Featured = repo links. Naukri: refresh profile daily before 9am (recency boosts ranking); keywords field stuffed honestly: Apex, LWC, SOQL, Triggers, REST API, Integration, Sales Cloud, Service Cloud, Financial Services Cloud, SFDX.
  3. Tracker (sheet): Company · Role · Source · Date · Contact · Status · Next action. Every touch gets logged.
  4. Apply: 10 today — LinkedIn + Naukri, filter "Salesforce developer" 0–5 yrs, include partner firms. DM: 5 referral messages (template in Reference) to devs at Salesforce partners.
• TrailheadApex Integration Services — REST callouts unit40m
• DrillAnswer aloud — 5 questions30m
  Questions + key points

  • Why Named Credentials over hardcoded endpoints? (secrets, rotation, principals)
  • Which OAuth flow for server-to-server and why? (client credentials / JWT; no human)
  • "Uncommitted work pending" — what happened? (DML before callout; reorder or async)
  • Typed vs untyped JSON handling? (wrapper vs Map casts; when each)
  • How do you make an integration idempotent? (upsert + External Id; retry-safe)
• Comm3 × 2-min explainers45m
  ① a callout end-to-end ② OAuth flows in plain words ③ your C1 design (interface + provider = say "I designed for mockability").

Yesterday you called out; today the world calls you — plus the event-driven patterns (Platform Events, CDC) that separate 5-year answers from 2-year answers.

• TheoryExposing Apex REST50m
  Open theory — @RestResource end to end

  @RestResource(urlMapping='/v1/leads/*')
  global with sharing class LeadIntakeApi {
      global class LeadRequest { global String firstName, lastName, email, product; }
      global class ApiResponse { global Boolean ok; global String message, id; }
  
      @HttpPost
      global static ApiResponse create() {
          RestRequest req = RestContext.request;
          ApiResponse out = new ApiResponse();
          try {
              LeadRequest body = (LeadRequest) JSON.deserialize(
                  req.requestBody.toString(), LeadRequest.class);
              // dedupe check + insert here...
              out.ok = true; out.id = newLead.Id;
          } catch (Exception e) {
              RestContext.response.statusCode = 400;
              out.ok = false; out.message = e.getMessage();
              ErrorLogger.log(e, 'LeadIntakeApi', 'create', null);
          }
          return out;                    // serialized to JSON automatically
      }
  }

  • URL: https://<mydomain>.my.salesforce.com/services/apexrest/v1/leads/. Wildcard path parsed from req.requestURI.
  • One class per urlMapping; one method per verb (@HttpGet/Post/Put/Patch/Delete).
  • Auth story for interviews: caller uses a Connected App → OAuth token (client credentials/JWT) → Bearer header → API call counts against daily API limits; give the API user a minimal permission set.
  • Return typed wrappers (never raw SObjects — you'll leak fields); set statusCode deliberately (201/400/404/409).
• TheoryTesting integrations — HttpCalloutMock & RestContext40m
  Open theory — no real callouts in tests, ever

  @isTest
  global class RateApiMock implements HttpCalloutMock {
      global HttpResponse respond(HttpRequest req) {
          HttpResponse res = new HttpResponse();
          res.setStatusCode(200);
          res.setBody('{"base_code":"USD","conversion_rates":{"INR":83.2}}');
          return res;
      }
  }
  // in the test:
  Test.setMock(HttpCalloutMock.class, new RateApiMock());
  Test.startTest();  ExchangeRateService.refresh('USD');  Test.stopTest();
  Assert.areEqual(83.2, [SELECT Rate__c FROM Exchange_Rate__c
                         WHERE Pair_Key__c = 'USD-INR'].Rate__c);

  • Variants: StaticResourceCalloutMock (body from a Static Resource), or one mock class that switches on req.getEndpoint() for multi-endpoint flows.
  • Testing inbound REST: build the context yourself — RestContext.request = new RestRequest(); request.requestBody = Blob.valueOf(jsonString); then call the method directly and assert the wrapper + statusCode.
• TheoryPlatform Events, CDC & picking a pattern50m
  Open theory — event-driven Salesforce

  • Platform Event = a custom pub/sub message (KYC_Result__e, define like an object). Publish: EventBus.publish(new KYC_Result__e(Status__c='CLEAR')); from Apex/Flow/API. Subscribe: an after-insert trigger on the event, a flow, or external systems (CometD/Pub-Sub API). Config per event: publish immediately (even if txn rolls back) vs after commit.
  • Change Data Capture = system-generated events on record changes (AccountChangeEvent) — enable per object; carries changed fields + header. For keeping external systems in sync without polling.
  • Decision one-liners: fire-and-forget notify → Platform Event · replicate record changes → CDC · declarative SOAP ping with retries → Outbound Message · external system pulls → REST API + updated-since query. Full table: Reference.
  • Test trick: events publish at Test.stopTest(), or force delivery with Test.getEventBus().deliver();.
• BuildC2 — LeadIntake REST API + tests + Workbench proof1.5h
  Spec

  Implement LeadIntakeApi per the skeleton: dedupe by email against existing Leads/Contacts → return 409-style ok=false, message='duplicate'; happy path creates the Lead and returns its Id. Test class covers happy/duplicate/malformed-JSON. Then prove it live: Workbench (workbench.developerforce.com) → utilities → REST Explorer → POST /services/apexrest/v1/leads/ with a JSON body — screenshot for the README.

• BuildC3 — mocks for C1 · PE1 — KYC_Result__e event + trigger1.5h
  Spec

  1. C3: mock suite for ExchangeRateService — 200 path, 500 path (assert ErrorLogger row), garbage-JSON path. Coverage of the service ≥ 90%.
  2. PE1: define KYC_Result__e (fields: Account_Id__c Text, Status__c Text). After-insert trigger on the event updates Account.KYC_Status__c. Publish from anonymous Apex; verify. Test with Test.getEventBus().deliver(). This exact pipeline returns in the capstone Day 20.
• TrailheadApex Integration Services — finish badge45m
• DrillAnswer aloud — 5 questions30m
  Questions + key points

  • Expose an Apex REST service end-to-end, including auth. (annotation → URL → Connected App/OAuth → status codes)
  • How do you test callouts? (setMock; why tests forbid real callouts)
  • Platform Events vs CDC vs Outbound Message? (custom message vs record-sync vs declarative SOAP)
  • Publish immediately vs after commit? (audit/log events vs transactional consistency)
  • How would an external banking system push loan status into Salesforce? (your C2, narrated — or platform event via API)
• Job huntDaily block — 10 apps or 5 apps + 3 DMs + 1 follow-up45m
• Comm3 × 2-min explainers45m
  ① inbound REST with auth ② mocking strategy ③ event-driven patterns speed-round.

LWC rounds fail on JavaScript, not on Salesforce. Today: modern JS survival kit, then your first two deployed components.

• TheoryJS survival kit for LWC interviews1.5h
  Open theory — the 12 things they actually ask

  const rates = [{ ccy: 'INR', rate: 83.2 }, { ccy: 'EUR', rate: 0.92 }];
  
  // arrow functions + array methods (map/filter/find/reduce/some)
  const codes  = rates.map(r => r.ccy);
  const high   = rates.filter(r => r.rate > 1);
  const inr    = rates.find(r => r.ccy === 'INR');
  const total  = rates.reduce((sum, r) => sum + r.rate, 0);
  
  // destructuring + spread + template literals
  const { ccy, rate } = inr;
  const copy  = { ...inr, updated: true };
  const label = `1 USD = ${rate} ${ccy}`;
  
  // optional chaining + nullish coalescing
  const name = response?.data?.account?.Name ?? 'Unknown';
  
  // promises & async/await
  async function loadRates() {
      try   { this.rows = await fetchRates({ base: 'USD' }); }
      catch (e) { this.error = e?.body?.message; }
  }

  • let/const (block scope) vs var (function scope, hoisted) — always const-first.
  • Arrow functions don't rebind this — why event handlers in LWC use them or class methods.
  • == vs === — always strict.
  • Promise states pending/fulfilled/rejected; async/await is syntax over promises; parallelize with Promise.all.
  • Modules: import { x } from 'y' — every LWC file is a module; export default class.
  • event.target (what was clicked) vs event.currentTarget (where the listener sits).
• TheoryLWC anatomy — bundle, reactivity, lifecycle, directives1.5h
  Open theory — how a component actually works

  • Bundle: myWidget/myWidget.html + .js + .js-meta.xml (+ optional .css, .svg). Name camelCase in code, kebab-case in markup: <c-my-widget>.
  • Reactivity: all class fields are reactive — reassignment re-renders. Mutating object/array internals is NOT tracked → reassign (this.rows = [...this.rows, newRow]) or decorate with @track (legacy deep-tracking). @api = public property/method (parent sets it). Getters compute derived display values.
  • Lifecycle order: constructor → @api props assigned → connectedCallback (fetch/subscribe) → render → renderedCallback (DOM ready — guard it, it re-runs on every render!) → disconnectedCallback (cleanup: intervals, subscriptions). errorCallback = boundary for child errors.
  • Directives: lwc:if={x} / lwc:elseif / lwc:else (modern; you'll still see legacy if:true), for:each={rows} for:item="row" + mandatory key={row.Id} (diffing identity).
  • Meta: isExposed, targets (AppPage/RecordPage/HomePage/quick action/utility bar) + targetConfigs (design-time props). Record pages auto-inject @api recordId and objectApiName.
  • Base components (lightning-*): card, input, button, combobox, datatable, spinner, record-form family. Toasts: dispatch ShowToastEvent from lightning/platformShowToastEvent.

  // helloExplorer.js
  import { LightningElement } from 'lwc';
  export default class HelloExplorer extends LightningElement {
      name = '';
      topics = [{ id: 1, label: 'Apex' }, { id: 2, label: 'LWC' }];
      get greeting() { return this.name ? `Hello, ${this.name}!` : 'Type your name'; }
      handleInput(event) { this.name = event.target.value; }
  }

  <!-- helloExplorer.html -->
  <template>
    <lightning-card title="Hello Explorer">
      <div class="slds-p-around_medium">
        <lightning-input label="Name" onchange={handleInput}></lightning-input>
        <p lwc:if={name}>{greeting}</p>
        <p lwc:else>Waiting…</p>
        <template for:each={topics} for:item="t">
          <lightning-badge key={t.id} label={t.label}></lightning-badge>
        </template>
      </div>
    </lightning-card>
  </template>

• BuildL1 helloExplorer + L2 accountsTableStatic — deploy to an App Page3h
  Spec + deploy commands

  1. L1: the component above, typed by hand, plus a "clear" button and a computed character count getter.
  2. L2: lightning-datatable with hardcoded column defs (label/fieldName/type) + 10 static account rows; sortable columns (handle onsort — array sort + reassign, your JS practice applied).
  3. Deploy: sf project deploy start --source-dir force-app (or right-click → Deploy in VS Code). Lightning App Builder → new App Page → drop both components → activate.

  Done when: both live on an app page in your org; sorting works; you can explain why the sort handler reassigns the array.

• TrailheadLightning Web Components Basics — first half45m
• DrillAnswer aloud — 6 questions30m
  Questions + key points

  • Lifecycle hooks in order, with one use case each.
  • @api vs @track vs plain fields? (public vs deep-track legacy vs default reactivity)
  • Why is key required in for:each? (diff identity, no index keys)
  • var vs let vs const; == vs ===?
  • Arrow functions and this? (lexical this — why handlers break with function())
  • What does the meta.xml control? (exposure, targets, design props)
• Job huntDaily block45m
• Comm3 × 2-min explainers45m
  ① promises for a 10-year-old ② LWC lifecycle ③ reactivity rules. English only, no notes.
• PrepOrder Focus on Force PD1 practice exams (if not done)10m

"Wire vs imperative" is the #1 LWC interview question. Today you build accountSearch — the component you'll rebuild from scratch, timed, at the Day-14 gate.

• TheoryLightning Data Service — zero-Apex CRUD45m
  Open theory — the free layer everyone forgets

  • lightning-record-form — whole form from layout/fields in one tag (fastest). record-edit-form / record-view-form — per-field control with lightning-input-field. All respect FLS + sharing automatically, share a client cache, and need no Apex — say "I use LDS first, Apex only when it can't" in interviews.
  • uiRecordApi module: getRecord (@wire single record), getFieldValue, createRecord / updateRecord / deleteRecord (imperative promises), getRecordNotifyChange([{recordId}]) — tell the cache you changed data behind its back via Apex.
  • Decision: single-record display/edit → LDS. Lists, aggregates, cross-object logic, DML with business rules → Apex.
• Theory@wire vs imperative Apex — the real rules1.25h
  Open theory — cacheable, provisioning, refreshApex, errors

  // Apex controller
  public with sharing class AccountSearchController {
      @AuraEnabled(cacheable=true)                 // wire REQUIRES cacheable
      public static List<Account> search(String term) {
          String like = '%' + String.escapeSingleQuotes(term) + '%';
          return [SELECT Id, Name, Industry FROM Account
                  WHERE Name LIKE :like WITH USER_MODE LIMIT 20];
      }
      @AuraEnabled                                  // imperative (DML allowed)
      public static void updateRating(Id accId, String rating) {
          try {
              update new Account(Id = accId, Rating = rating);
          } catch (Exception e) {
              throw new AuraHandledException('Could not update: ' + e.getMessage());
          }
      }
  }

  // JS side
  import search from '@salesforce/apex/AccountSearchController.search';
  import { refreshApex } from '@salesforce/apex';
  
  export default class AccountSearch extends LightningElement {
      term = '';
      wiredResult;                       // hold provisioned value for refreshApex
  
      @wire(search, { term: '$term' })   // '$term' = reactive: re-runs on change
      wired(result) {
          this.wiredResult = result;
          const { data, error } = result;
          if (data)  { this.rows = data;  this.error = undefined; }
          if (error) { this.error = error.body?.message; }
      }
      async handleRefresh() { await refreshApex(this.wiredResult); }
  
      async handleSave() {               // imperative for DML
          try {
              await updateRating({ accId: this.selectedId, rating: 'Hot' });
              await refreshApex(this.wiredResult);
          } catch (e) { this.error = e.body?.message; }
      }
  }

  • Wire: declarative, cached client+server side, reactive to $params, runs on load — read-only views. cacheable=true forbids DML inside.
  • Imperative: you decide when (click, debounce), can hit non-cacheable methods, do DML.
  • refreshApex(provisionedValue) — re-runs the wire; you must have stored the whole provisioned object.
  • AuraHandledException — the only way your error message survives to e.body.message cleanly; anything else becomes a generic "internal error".
  • Debounce pattern for search-as-you-type: clearTimeout(this.t); this.t = setTimeout(() => { this.term = v; }, 300);
• BuildL3 — accountSearch (the gate component)3.5h
  Spec

  1. Search input (debounced 300ms) → wired search → datatable results; spinner while loading; friendly empty state; error toast on failure.
  2. Row action "Open" → NavigationMixin.Navigate to the record page. Row action "Mark Hot" → imperative updateRating → toast → refreshApex.
  3. Controller: both methods above + test class (happy, empty term, AuraHandledException path asserted with try/catch).
  4. Place on the App Page next to L1/L2.

  Done when: search feels instant, errors are human-readable, tests green. Tomorrow you rebuild this in 45 minutes — take notes on what slowed you down.

• TrailheadLightning Web Components and Salesforce Data45m
• DrillAnswer aloud — 5 questions30m
  Questions + key points

  • Wire vs imperative — when each? (the full answer, with cacheable + reactivity + DML)
  • What does cacheable=true actually do? (client cache + wire eligibility + no DML)
  • How does refreshApex work? (provisioned value, not the data)
  • Why AuraHandledException? (clean message to e.body.message)
  • LDS vs Apex — decision rule? (single-record CRUD free vs lists/logic)
• Job huntDaily block45m
• Comm3 × 2-min explainers45m
  ① wire vs imperative ② refreshApex ③ demo L3 on screen while narrating (record your screen — first demo rep).

Three communication routes, one mini service console, and the Week-2 gate. PD1 nightly questions start tonight.

• TheoryThe three communication routes1.5h
  Open theory — parent↔child↔stranger

  ① Parent → child: @api

  // child exposes:  @api caseRecord;  @api focus() { ... }
  <c-case-card case-record={selectedCase}></c-case-card>
  // parent calls a public method:
  this.template.querySelector('c-case-card').focus();

  ② Child → parent: CustomEvent

  // child dispatches (name: lowercase, no "on", no caps):
  this.dispatchEvent(new CustomEvent('caseselect', {
      detail: { caseId: this.caseRecord.Id }
  }));
  // parent listens in markup:
  <c-case-card oncaseselect={handleSelect}></c-case-card>
  // handleSelect(event) { this.selectedId = event.detail.caseId; }

  Defaults: bubbles:false, composed:false — the event stops at the parent; crossing shadow boundaries is opt-in and rarely right.

  ③ Unrelated components: Lightning Message Service

  // messageChannels/CaseSelected.messageChannel-meta.xml declares the channel
  import { publish, subscribe, MessageContext } from 'lightning/messageService';
  import CASE_SELECTED from '@salesforce/messageChannel/CaseSelected__c';
  
  @wire(MessageContext) messageContext;
  // publisher:
  publish(this.messageContext, CASE_SELECTED, { caseId: id });
  // subscriber (connectedCallback):
  this.sub = subscribe(this.messageContext, CASE_SELECTED,
      (msg) => this.load(msg.caseId));
  // disconnectedCallback: unsubscribe(this.sub);

  Decision: same DOM tree → props down, events up. Different regions/tabs (even LWC↔Aura↔Visualforce) → LMS. Table in Reference → LWC cheatsheet.

• BuildL4 — mini service console (3 components, all 3 routes)3h
  Spec

  1. caseListFiltered (parent): status combobox filter → wired case list → renders caseCard children (@api caseRecord).
  2. caseCard (child): shows subject/priority/age; click → CustomEvent caseselect up AND parent publishes on LMS channel.
  3. caseDetailPanel (stranger, separate region): subscribes to LMS → loads case via lightning-record-view-form; "Close case" button → imperative Apex → toast → refreshApex on the list (getRecordNotifyChange for the form).
  4. Seed 15 cases via anonymous script. Assemble on the App Page: list left, detail right.

  Done when: click a card on the left, detail loads on the right through LMS, closing a case updates both — narrate that flow once on video (it's a portfolio demo).

• BuildopportunityFxWidget — C1 meets LWC1h
  On the Opportunity record page (@api recordId): imperative call to a controller reading Exchange_Rate__c → show Amount in INR/EUR/GBP. Ties Week 2 into one demo.
• GateWeek-2 gate — timed rebuild + quiz1.5h
  The gate

  1. Timed: rebuild accountSearch (fresh component, 45 min): debounced input, wire, datatable, one imperative action, toast. Pass = works, even if ugly.
  2. Quiz /12, pass ≥ 9: future vs Queueable vs Batch vs Schedulable (4 pts) · callout after DML error · Named Credential why · mock a callout · expose REST + auth · PE vs CDC · wire vs imperative · refreshApex · the 3 communication routes.
• TrailheadFinish LWC Basics badge45m
• PD1Nightly 30 questions — starts tonight, every night through Day 2445m
  Log score + every wrong answer into a flashcard note. Trend matters more than tonight's number.
• Job huntDaily block45m
• CommWeekly review video — "My week 2"45m
  5 minutes: async, integration, LWC — what you built, with the app page on screen. Compare against the Week-1 video: you should hear the difference.

Lead-to-cash mechanics: what actually happens on lead convert, and the product/pricebook chain everyone fumbles in interviews.

• SetupSign up for the Financial Services Cloud trial org — today, it needs lead time15m
  salesforce.com → search "Financial Services Cloud trial" (30-day trial org with FSC + person accounts pre-enabled). Fallback if unavailable in your region: Trailhead FSC modules + mirror objects in your dev org (Day 18 has the fallback spec).
• TheoryLead lifecycle & conversion mechanics1.25h
  Open theory — what convert really does

  • Path: capture (web-to-lead / API / manual) → assignment rules route → nurture → convert → Account + Contact + (optional) Opportunity, lead flips to IsConverted=true with ConvertedAccountId/ContactId/OpportunityId.
  • Field mapping: standard fields map automatically; custom lead fields need the mapping in Setup → Lead Fields → Map Lead Fields.
  • What fires on convert (interview favorite): the lead's update triggers (before/after) and insert triggers on Account/Contact/Opportunity for the created records. Validation rules and required fields are skipped by default unless "Require Validation for Converted Leads" is enabled — a classic "why did bad data get through?" answer.
  • Convert from Apex:

  Database.LeadConvert lc = new Database.LeadConvert();
  lc.setLeadId(lead.Id);
  lc.setConvertedStatus('Qualified');   // from LeadStatus where IsConverted=true
  lc.setDoNotCreateOpportunity(false);
  Database.LeadConvertResult r = Database.convertLead(lc);

  • Fire assignment rules from Apex (they don't run on plain DML):

  Database.DMLOptions dmo = new Database.DMLOptions();
  dmo.assignmentRuleHeader.useDefaultRule = true;
  newLead.setOptions(dmo);
  insert newLead;

  Detect conversion in a trigger: Trigger.isUpdate && c.IsConverted && !Trigger.oldMap.get(c.Id).IsConverted.
• TheoryProducts, pricebooks & person accounts1.25h
  Open theory — the chain, drawn

  Product2 ──< PricebookEntry >── Pricebook2 (Standard + custom books)
                       │
                       ▲
  Opportunity ──< OpportunityLineItem (references PricebookEntry)
  Quote ──────< QuoteLineItem  (mirrors OLI)

  • Rules that make it an interview question: a product must have a Standard pricebook entry before any custom pricebook entry; an Opportunity locks to one pricebook (Pricebook2Id) once it has line items; OLI stores UnitPrice × Quantity → TotalPrice; Amount rolls up from OLIs when products are used.
  • In tests: Test.getStandardPricebookId() gives you the standard book without SeeAllData.
  • Campaigns: Campaign ──< CampaignMember (Lead/Contact) — attribution basics; Opportunity Contact Roles for who-influenced-what.
  • Person Accounts (FSC prerequisite): B2C model where Account+Contact merge into one record — IsPersonAccount, PersonContactId, person fields like PersonEmail. Enabled by Salesforce support, irreversible; account record types split business vs person. Code smell to avoid: assuming every Account has separate Contacts — check IsPersonAccount. Your FSC trial org has them on; explore there.
• BuildSales pipeline config + T5 conversion trigger + web-to-lead3h
  Spec

  1. Config (admin muscles): custom lead fields Product_Interest__c (picklist: Savings/Loan/Investment) + Monthly_Income__c (Currency) with lead field mapping to Opportunity/Account; one assignment rule (Banking leads → you, else queue "Unassigned Leads"); auto-response rule with a template.
  2. Web-to-lead: generate the form (Setup → Web-to-Lead), save the HTML locally, open in a browser, submit — watch a lead arrive with assignment applied. (This HTML file becomes the capstone intake later.)
  3. T5 LeadTrigger: on conversion (detect the flip), copy Product_Interest__c onto the new Opportunity's Type-style custom field and create a follow-up Task for the opp owner ("Call within 24h"). Bulk-safe (convert 10 via Apex in one go in your test). Handler framework, tests, done.

  Done when: submit form → lead assigned → convert → opp carries data + task exists; tests cover bulk conversion via Database.convertLead in a loop of LeadConvert objects (one convertLead call with a List).

• TrailheadLeads & Opportunities for Lightning Experience — key units45m
• DrillAnswer aloud — 6 questions30m
  Questions + key points

  • What exactly happens on lead conversion? (records created, field mapping, IsConverted flags)
  • Which triggers fire on convert? Do validation rules run? (update on lead + inserts on A/C/O; skipped unless the setting)
  • Draw the product → pricebook → OLI chain. (from memory, with the standard-entry-first rule)
  • How do you run assignment rules from Apex? (DMLOptions header)
  • What is a person account and what changes in code? (merged A+C, IsPersonAccount checks)
  • Opportunity Amount with products — where does it come from? (OLI rollup)
• Job huntDaily block45m
• PD1Nightly 30 questions45m
• Comm3 × 2-min explainers45m
  ① lead conversion mechanics ② the product chain (draw while talking) ③ person accounts.

Case routing end-to-end and the entitlement/milestone model — the part of Service Cloud developers actually get asked about.

• TheoryCase lifecycle & routing1h
  Open theory — channels in, rules through, agents out

  • Channels in: Web-to-Case, Email-to-Case (On-Demand = Salesforce-hosted routing address; the "agent" variant runs behind a firewall), portals/communities, API, phone (CTI).
  • Routing: Queues hold ownership; Case Assignment Rules (one active rule, ordered entries) place cases; Auto-Response Rules acknowledge; Escalation Rules are time-based (re-assign + notify when age crosses thresholds); Omni-Channel pushes work to available agents — queue-based or skills-based routing, presence statuses, capacity weights (know the concepts + words).
  • Support Processes = status subsets per record type (e.g., Onboarding case vs Complaint case).
  • Knowledge: Knowledge__kav versioned articles, record types + data categories; attach to cases; deflection.
  • Console note for devs: LWCs on record pages work in console apps; workspace tabs are manipulable via lightning/platformWorkspaceApi — name-drop, don't deep-dive.
• TheoryEntitlements & milestones — the SLA engine1.5h
  Open theory — the model + the auto-complete pattern

  Account ──< Entitlement (what support the customer bought)
                  │  uses Entitlement Process (versioned SLA timeline)
                  │        └── Milestones (MilestoneType: "First Response", "Resolution")
  Case ── linked to Entitlement → CaseMilestone rows track TargetDate vs CompletionDate

  • Flow: case gets an Entitlement → its process instantiates CaseMilestone rows with target times (business hours aware); violation = SLA breach; escalation actions fire on warning/violation.
  • The dev pattern — auto-complete a milestone when the SLA-satisfying thing happens (first agent comment/email):

  public static void completeMilestone(Set<Id> caseIds, String milestoneName) {
      List<CaseMilestone> open = [
          SELECT Id FROM CaseMilestone
          WHERE CaseId IN :caseIds
            AND MilestoneType.Name = :milestoneName
            AND CompletionDate = null];
      for (CaseMilestone cm : open) { cm.CompletionDate = System.now(); }
      update open;
  }

  • Trigger it from CaseComment/EmailMessage after-insert (agent-authored only). This exact snippet is a beloved interview scenario: "how do you stop the First Response clock?"
• BuildService config — queue, rules, entitlement process1.5h
  Spec

  1. Queue "Onboarding Ops" (Case); assignment rule: Origin=Web → queue, Priority=High → you; auto-response template; escalation rule: High + 2h unresolved → escalate.
  2. Enable Entitlement Management → MilestoneTypes "First Response" (2h) + "Resolution" (24h) → Entitlement Process "Standard Support" → Entitlement on 3 test accounts; set the case lookup so new cases pick it up (entitlement auto-selection via trigger: copy Account's active entitlement onto the case — small T-snippet, write it).
  3. Create cases via web-to-case form + manual; watch CaseMilestone rows appear (add the Milestones related list / Milestone Tracker to the case page).
• BuildT6 milestone auto-complete + L6 caseSlaTracker LWC1.5h
  Spec

  1. T6: CaseComment after insert (comment by internal user) → completeMilestone(caseIds, 'First Response'). Bulk-safe; tests: case with entitlement, add comment, assert CompletionDate set.
  2. L6 caseSlaTracker (Case record page): imperative Apex loads open CaseMilestones (@api recordId); render name + countdown to TargetDate; setInterval in connectedCallback ticks it down, cleared in disconnectedCallback (say why in the README — interval leaks are an interview probe); red style under 30 min.

  Done when: comment on a case completes First Response live while the tracker shows it; interval verified cleaned (console.log on disconnect).

• TrailheadService Cloud for Lightning Experience — key units45m
• DrillAnswer aloud — 6 questions30m
  Questions + key points

  • Entitlement vs Entitlement Process vs Milestone vs CaseMilestone? (the model, drawn)
  • How do you auto-complete "First Response"? (the snippet, narrated)
  • Queues vs assignment rules vs Omni-Channel? (hold vs place vs push)
  • Email-to-Case flavors? (on-demand vs behind-firewall agent)
  • Escalation rules — what triggers them? (time thresholds, business hours)
  • Where would Knowledge fit in a banking service desk? (articles, categories, deflection)
• Job huntDaily block45m
• PD1Nightly 30 questions45m
• Comm3 × 2-min explainers45m
  ① entitlement model ② case routing tour ③ demo L6 on screen.

The two judgment topics that mark you as senior: when NOT to write code, and who-sees-what from OWD to Apex managed sharing.

• TheoryThe Flow landscape + the decision framework1.5h
  Open theory — flow types, invocables, when-which

  • Types: record-triggered (before-save = fast field updates, no related records; after-save = everything else), screen flows (guided UI), scheduled, autolaunched (called by Apex/API), platform-event-triggered. Workflow Rules + Process Builder are retired-in-spirit — migrate answers to Flow.
  • Decision framework (say it this cleanly): declarative first for field updates, simple record creation, guided screens, approvals. Apex when: complex collection logic, cross-object transforms at volume, callouts with retry/error engineering, anything needing unit tests, reusable services. Watch-outs for flow at scale: loops with DML inside, no bulk-safe error isolation, hard to code-review.
  • Order reminder: before-save flows → before triggers → after triggers → after-save flows.
  • Apex ⇄ Flow bridges:

  public class KycActions {
      public class Request  { @InvocableVariable(required=true) public Id accountId; }
      public class Result   { @InvocableVariable public String status; }
  
      @InvocableMethod(label='Run KYC Check' description='Calls KYC service')
      public static List<Result> run(List<Request> requests) {   // ALWAYS list-in, list-out
          List<Result> out = new List<Result>();
          for (Request r : requests) { /* bulk-safe work */ }
          return out;
      }
  }
  // Apex calling a flow:
  // new Flow.Interview.My_Flow(new Map<String,Object>{'recordId'=>id}).start();

• TheorySharing architecture — OWD to Apex managed sharing1.5h
  Open theory — the who-sees-what ladder

  1. Profiles / Permission Sets — object CRUD + FLS (what kind of access). Modern orgs: minimal profile + permission-set-group model.
  2. OWD (org-wide defaults) — the baseline per object: Private / Read / Read-Write / Controlled by Parent. Everything below only opens up from here…
  3. Role hierarchy — managers see subordinates' records (grant access via hierarchies).
  4. Sharing rules — owner-based or criteria-based, to roles/groups. Restriction rules are the rare "take away" tool.
  5. Manual sharing / Teams (account/case/opportunity teams).
  6. Apex managed sharing — programmatic rows in the object's Share table:

  // custom object Loan_Application__c → share table Loan_Application__Share
  Loan_Application__Share sh = new Loan_Application__Share(
      ParentId      = loanApp.Id,
      UserOrGroupId = complianceGroupId,
      AccessLevel   = 'Read',
      RowCause      = Schema.Loan_Application__Share.RowCause.Compliance_Review__c);
  insert sh;   // Apex sharing reasons: custom objects only

  • Implicit sharing exists (account ↔ child cases/opps) — name it if asked why someone "mysteriously" sees a case.
  • Debug path for "user can't see record" (rehearse verbatim): object perms → FLS → OWD → role → sharing rules → manual/teams → share table rows.
  • Record locks: parallel updates → UNABLE_TO_LOCK_ROW; mitigate with SELECT ... FOR UPDATE, retry, or serializing writes (say "I'd queue updates through one async path").
• BuildF2 — three flows (before-save, screen + fault path, invocable action)2h
  Spec

  1. Before-save flow on Case: default Priority by Origin (Web→Medium, Phone→High) — note in README why this beats a before trigger here (no code to maintain) and when it wouldn't (complex lookups at volume).
  2. Screen flow "Log a Complaint": screen (account picker + description) → create Case + follow-up Task → fault path on the create element → screen showing the error + Error_Log__c record via… your invocable logger (wrap ErrorLogger in an @InvocableMethod — 10 lines).
  3. Invocable KYC stub: the KycActions class above returning a fake status; call it from the screen flow; you'll swap the fake for the real callout in the capstone.

  Done when: all three run in the org; you can argue flow-vs-apex for each with a straight face.

• BuildT7 — Apex managed sharing kata + "Flow vs Apex" one-pager1h
  Custom object Loan_Application__c (Status picklist) with OWD Private + Apex sharing reason "Compliance Review"; trigger: Status = Under Review → share Read with public group "Compliance"; Status leaves review → delete the share row. Tests with runAs proving visibility flips. Then write the one-page flow-vs-apex decision doc into the repo README — interviewers love being handed a framework.
• TrailheadBuild Flows with Flow Builder (key units) + Data Security badge1h
• DrillAnswer aloud — 6 questions30m
  Questions + key points

  • Flow vs Apex — your framework? (declarative-first + the escape hatches; give examples both ways)
  • Before-save flow vs before trigger — order and when each?
  • Walk the sharing ladder from OWD to manual. (the numbered list, fluent)
  • User can't see a record — debug path? (verbatim rehearsed)
  • What is Apex managed sharing and when did you use it? (T7 story: compliance visibility)
  • @InvocableMethod signature rules? (static, list-in/list-out, one per class)
• Job huntDaily block45m
• PD1Nightly 30 questions45m
• Comm3 × 2-min explainers45m
  ① your flow-vs-apex framework ② the sharing ladder ③ the T7 compliance story (this becomes a STAR story).

FSC demystified: it's Sales + Service + a managed package of banking objects. Learn the household model cold — it's the one thing every FSC interviewer checks.

• TheoryWhat FSC is — and what "managed package" means for you45m
  Open theory — the platform view

  • FSC = a managed package (namespace FinServ__) installed on core Sales + Service Cloud, plus verticals: retail banking, wealth management, insurance, mortgage.
  • Dev implications (interview gold): objects/fields arrive namespaced (FinServ__FinancialAccount__c, and in SOQL: FinServ__PrimaryOwner__c); you can't modify package code — you extend with your own triggers/LWCs/flows on their objects; upgrades are Salesforce-pushed, so never depend on package internals; your triggers coexist with package automation (order matters — test!).
  • Everything you learned in Weeks 1–2 IS FSC development: triggers on FinServ objects, LWCs on FSC record pages, integrations to core banking systems. FSC-specific knowledge = the data model + a feature vocabulary. That's why this is crackable in days, not years.
• TheoryClients, households & relationships1.25h
  Open theory — the household model (THE FSC question)

              Account (record type: Household)
                │  membership via AccountContactRelation (ACR)
     ┌──────────┴──────────┐
   Person Account        Person Account
   "Rahul Mehta"         "Priya Mehta"
     │ FinServ__PrimaryOwner__c        (roles on ACR: Client, Spouse, …)
     └──< FinServ__FinancialAccount__c  (Checking, Loan, Investment…)
               └──< FinServ__FinancialAccountRole__c (joint owners, beneficiaries)

  • Client modeling: two options — Person Accounts (recommended, what your trial uses) or the legacy Individual model (Account + Contact 1:1 pairs). Know both exist and why PA won (single record, simpler code).
  • Household = an Account with the Household record type. Members join via AccountContactRelation — the standard object FSC leans on so one person can belong to several households/businesses with roles. FSC adds fields (primary group, roles) and rollup behavior on top.
  • Reciprocal Roles (FinServ__ReciprocalRole__c): paired titles — "Power of Attorney ↔ Grantor", "Accountant ↔ Client" — used by Contact-Contact / Account-Account relationship objects (FinServ__ContactContactRelation__c, FinServ__AccountAccountRelation__c).
  • Actionable Relationship Center (ARC) — the UI graph that renders all of this; name it when asked "how does a banker see the family?"
• TheoryFinancial Accounts & Rollup-By-Lookup1h
  Open theory — the money objects + RBL

  • FinServ__FinancialAccount__c — the star: record types per product (Bank Account, Loan, Investment, Credit Card…), key fields FinServ__PrimaryOwner__c (→Account), FinServ__Balance__c, FinServ__Household__c.
  • FinServ__FinancialAccountRole__c — joint owners/beneficiaries/trustees (who else touches this account).
  • Supporting cast: FinServ__AssetsAndLiabilities__c (held-away assets), FinServ__FinancialGoal__c, FinServ__FinancialHolding__c + FinServ__Securities__c (wealth positions).
  • Rollup-By-Lookup (RBL): FSC's config-driven rollups (FinServ__RollupByLookupConfig__c) — Total Bank Deposits, Total Investments on the client and household — computed by the package on lookup relationships (where standard rollup summary fields can't go, since they need master-detail). Your Day-5 Apex rollup is the same idea hand-built: say exactly that in interviews. At scale some orgs move rollups to Data Processing Engine — name-drop only.
• BuildFSC field trip — build a family, query everything3h
  Spec (trial org) + fallback (vanilla org)

  1. In the FSC trial: create person accounts Rahul + Priya → household "Mehta Household" with both as members (roles) → 4 financial accounts (checking, savings, home loan, investment) with balances → add a joint-owner FinancialAccountRole → watch household RBL totals update.
  2. 8 SOQLs committed to the repo: ① all FAs of a client with balances ② household members via ACR ③ FAs rolled to household ④ joint owners of an FA ⑤ total balance by record type (aggregate) ⑥ clients with loans over X ⑦ contact-contact relations with roles ⑧ life-events-style query on any related list you find. Explore Object Manager to find real API names — that exploration IS the learning.
  3. Draw the model by hand (paper), photograph, commit as fsc-data-model.jpg. You will redraw this in interviews.
  4. Fallback (no trial): mirror it in your dev org: Financial_Account__c (record types, Balance__c, Primary_Owner__c lookup→Account), Financial_Account_Role__c, household = Account record type + AccountContactRelation (enable "Allow users to relate a contact to multiple accounts" in Account Settings). Same queries, your own namespace — and your Day-5 rollup plays the RBL part.
• TrailheadFinancial Services Cloud Basics (+ any FSC data-model module)1h
• DrillAnswer aloud — 6 questions30m
  Questions + key points

  • How does FSC model a household? (Account record type + ACR membership + roles — whiteboard it)
  • Why ACR instead of Contact.AccountId? (many-to-many: one person, many households/businesses)
  • Person Account vs Individual model? (merged record vs A+C pairs; PA recommended)
  • What is Rollup-By-Lookup and how does it differ from rollup summary fields? (config rollups over lookups vs master-detail-only RSF)
  • Name 6 FSC objects and their jobs. (glossary in Reference → FSC glossary)
  • What changes for a developer when objects come from a managed package? (namespace, no source edits, upgrade safety, coexisting automation)
• Job huntDaily block45m
• PD1Nightly 30 questions45m
• Comm3 × 2-min explainers45m
  ① the household model, drawing while talking ② RBL vs your Apex rollup ③ "what is FSC" for a non-technical listener.

The FSC feature vocabulary that fills out your answers — then the capstone repo goes live.

• TheoryFSC feature vocabulary1.25h
  Open theory — one confident sentence per feature

  • Action Plans: reusable task checklists from templates (ActionPlanTemplate → ActionPlan) attached to records — the standard answer for "repeatable onboarding/KYC process with document checklist items."
  • Life Events: timeline of client milestones (marriage, home purchase, retirement) on the person account page — advisors act on them; devs automate creating them from data.
  • Interaction Summaries: structured, compliance-friendly meeting notes with role-based visibility — the wealth-management darling.
  • Compliant Data Sharing (CDS): participant-role-based access on sensitive records (deals, interactions) — finer than sharing rules, built for "only the deal team sees this."
  • Financial Deals (corporate/investment banking) — pipeline objects governed by CDS.
  • Insurance vertical objects (name-drop table): InsurancePolicy, InsurancePolicyParticipant, Claim, ClaimParticipant.
  • Mortgage objects: ResidentialLoanApplication + document checklist flow.
  • Data Processing Engine (DPE): batch transform engine some FSC orgs use for heavy rollups.
  • Interview stance: you don't claim years with these — you claim the model: "I know the objects and where custom code hooks in; here's my capstone on that data model."
• TheoryCapstone architecture — read it like a design review45m
  Open the architecture

  [Web-to-Lead form]──┐
  [REST LeadIntake]───┤→ Lead (+dedupe trigger)
                      │      └─ convert → Person Account + Household
                      │                    └─ Financial_Account "Pending KYC"
                      │                          └─ Queueable KYC callout (Named Cred)
                      │                                ├─ success → Platform Event KYC_Result__e
                      │                                │    └─ PE trigger → Onboarding Case
                      │                                │         └─ Entitlement + Milestones
                      │                                │              └─ escalation + L6 tracker
                      │                                └─ failure → Finalizer retry + Error_Log__c
  [Nightly Schedulable] → Dormant Account Batch → summary email
  [LWC] newFinancialAccountWizard · clientFinancialSummary · caseSlaTracker
  [Flow] before-save case defaults · screen flow "Service Request" · invocable KYC

  Notice: every box is something you already built in Weeks 1–3. The capstone is assembly + polish, not new invention. That's also your interview line: "I designed it so each piece demonstrates one platform capability."

• BuildAction Plan template + auto-attach flow (FSC org)1h
  Template "Client Onboarding" (5 tasks: KYC docs, welcome call, product setup, first review, feedback). Record-triggered flow: new Household → create Action Plan from template. Fallback org: a Task-checklist subflow does the same job — note the equivalence in the README.
• BuildCapstone kickoff — repo, objects, intake3h
  Spec

  1. Repo #3 bank-onboarding-capstone: sfdx project, README skeleton (problem → architecture diagram above → setup steps), data/seed.apex script.
  2. Objects (fallback org) / field additions (FSC org): KYC fields on Lead (Product_Interest__c, Monthly_Income__c — reuse Day 15), KYC_Status__c on Account, Financial_Account object per Day 18 fallback if needed.
  3. Intake: port the web-to-lead form + your C2 REST endpoint into this repo/org; port the dedupe trigger (T1 logic, now on Lead by email+phone). All with tests from day one.

  Done when: both intake paths create deduped Leads in the capstone org; repo public with the architecture in the README.

• DrillAnswer aloud — 5 questions30m
  Questions + key points

  • What are Action Plans and when would you use them? (templated checklists; onboarding/KYC)
  • Compliant Data Sharing vs sharing rules? (participant roles on the record vs org-wide criteria)
  • Where does custom code hook into FSC? (triggers on FinServ objects, LWCs on FSC pages, integrations, flows)
  • Name the insurance-vertical objects. (policy, participants, claim)
  • Pitch your capstone in 90 seconds. (first rehearsal of the money answer)
• Job huntDaily block45m
• PD1Nightly 30 questions45m
• Comm3 × 2-min explainers45m
  ① FSC feature vocabulary speed-round ② capstone architecture from the diagram ③ the 90-second pitch, take two.

Pure build day. By tonight a lead entering either door comes out the other end as a KYC-checked client with an onboarding case.

• BuildConversion automation2h
  LeadTrigger (T5 evolved): on qualified conversion → ensure Household exists (create if not) → person account linked as member (ACR) → create Financial_Account "Pending KYC" owned by the client. Bulk-safe for 50 conversions; tests prove household reuse (same family email domain → same household — document the naive matching rule honestly).
• BuildKYC Queueable — callout, finalizer retry, logging2h
  Queueable(AllowsCallouts) fired from the conversion path (post-commit safe): calls the KYC endpoint via Named Credential (use a mock endpoint or your RateProvider-style interface with a stub — offline demo must work), writes KYC_Status__c, Finalizer retries once on failure then logs. Tests with HttpCalloutMock: clear, flagged, 500+retry paths.
• BuildPlatform Event → Onboarding Case1.5h
  KYC job publishes KYC_Result__e; event trigger creates the Onboarding Case (queue "Onboarding Ops", entitlement attached → milestones start). Why an event instead of direct DML? Decoupling + replay — put that sentence in the README, it WILL come up.
• BuildEnd-to-end test pass1h
  One integration-style test: intake → convert → (mocked) KYC → deliver event → assert case + milestones. Plus: run the whole thing live in the org once, screen-recording it — raw footage for the demo video.
• DrillPitch rehearsal — pipeline edition30m
  Explain the whole pipeline in 3 minutes to your phone camera, using only the architecture diagram. This is 60% of your future "walk me through your project" answer.
• Job huntDaily block45m
• PD1Nightly 30 questions45m
• Comm1 explainer — today's hardest bug, out loud30m
  Whatever fought you today, narrate the debugging story — that's a live STAR story being minted.

The capstone gets its face: the account wizard, the financial summary, live SLAs — then the Week-3 gate.

• BuildService side — entitlements + milestone trigger + escalation1h
  Port Day-16 config into the capstone org: entitlement process on Onboarding Cases, T6 milestone auto-complete, escalation rule, L6 tracker on the case page.
• BuildnewFinancialAccountWizard LWC2.5h
  Spec

  1. 3 steps via lwc:if state machine: ① type (combobox: Savings/Loan/Investment) ② details (amount, nickname — validate > 0, required) ③ confirm (summary + submit).
  2. Submit → imperative Apex (with sharing, USER_MODE) creates the Financial Account linked to the client (@api recordId from the account page) → success toast → NavigationMixin to the new record. Errors → AuraHandledException surfaced in the wizard, not a toast-and-pray.
  3. Progress indicator (lightning-progress-indicator) across steps. Tests on the controller; manual test on a person account page.
• BuildclientFinancialSummary LWC1.5h
  On the account page: wired Apex aggregate (SUM Balance GROUP BY record type) → tiles per product type + grand total; refreshApex after the wizard creates an account (LMS or getRecordNotifyChange — your choice, justify it in README). FSC org: sanity-check your totals against the package RBL fields and note the comparison.
• GateWeek-3 gate — models from memory + quiz1.5h
  The gate

  1. Whiteboard test: draw all three from blank paper: sales product chain · entitlement model · FSC household. Record yourself narrating each (3 min each). Fumble = redo that theory tomorrow morning.
  2. Quiz /12, pass ≥ 9: lead convert mechanics · triggers on convert · product chain rules · milestone auto-complete · queues vs omni · flow-vs-apex framework · sharing ladder · debug "can't see record" · household via ACR · RBL vs RSF · person accounts · managed-package implications.
• Job huntDaily block + follow-ups on week-2 applications45m
• PD1Nightly 30 questions45m
• CommWeekly review video — "My week 3"30m
  5 minutes with the capstone on screen. You now have a project worth talking about — sound like it.

Finish the build, then learn to talk about shipping it — the deployment question is asked in literally every 5-year interview.

• BuildNightly batch + screen flow + funnel dashboard2h
  Port B1 (dormant flagger) into the capstone + schedule 2 AM. Screen flow "Service Request" for reps (case + task, fault path). Report "Onboarding Funnel" (leads → converted → KYC clear → case closed) + one dashboard — your admin skills on display next to code.
• BuildREADME, seed script, demo video2h
  The polish checklist

  1. README: problem statement (3 lines) → architecture diagram → feature list mapped to platform capabilities → setup (sf org login web, deploy command, data/seed.apex) → test instructions + coverage screenshot → "design decisions" section (event decoupling, finalizer retry, flow-vs-apex calls, security model).
  2. Seed script: one Execute-Anonymous file that makes a fresh org demo-able in 2 minutes.
  3. Demo video (3–4 min): macOS screen record (Cmd+Shift+5) + your voice: form submit → lead → convert → KYC → case with live SLA → wizard → summary tiles. Upload unlisted (YouTube/Loom), link in README + resume. This video does more shortlisting work than any bullet point.
• TheoryDeployment & DevOps — the interview answer1.5h
  Open theory — environments, deploy paths, CI/CD vocabulary

  • Environments: Developer/Developer Pro sandbox (metadata + no/partial data) → Partial Copy → Full Copy (staging/UAT) → Production. Scratch orgs = disposable source-driven orgs from config/project-scratch-def.json (true CI use).
  • Deploy paths: Change Sets (clicky, org-to-org, no history) vs source-driven with sf CLI: sf project deploy start --source-dir force-app --target-org UAT (+ --dry-run, --tests flags) vs unlocked packages (versioned metadata bundles) vs commercial CI tools (Gearset/Copado) vs DevOps Center (Salesforce's free pipeline UI on top of Git).
  • Your scripted answer (own it, it's true): "My projects are source-tracked in Git with the sf CLI; feature branches, PRs, deploy with tests to a target org, and I've set up a GitHub Actions workflow that runs sf project deploy validate on pull requests. In client orgs I'd slot into whatever the pipeline is — change sets, Copado, DevOps Center — the Git discipline is the same."
  • Bonus points vocabulary: --dry-run validation deploys, test levels (RunLocalTests for prod), destructive changes manifest, profiles-vs-permission-sets in version control (spiky topic — permission sets deploy cleaner).
  • Actually add the GitHub Action to the capstone (20 min, template below) so the sentence above is verifiably true:

  # .github/workflows/validate.yml
  name: validate
  on: [pull_request]
  jobs:
    validate:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
        - run: npm install -g @salesforce/cli
        - run: echo "$SFDX_AUTH_URL" | sf org login sfdx-url --sfdx-url-stdin -a ci
          env: { SFDX_AUTH_URL: ${{ secrets.SFDX_AUTH_URL }} }
        - run: sf project deploy validate --source-dir force-app --target-org ci --test-level RunLocalTests

• BuildAdd the CI workflow to the capstone repo30m
• DrillDeployment answer + 4 questions30m
  Questions

  • Describe your deployment process. (the scripted answer, verbatim, twice)
  • Change sets vs CLI vs packages — trade-offs?
  • Sandbox types and what you'd use each for?
  • How do you make sure a deploy doesn't break prod? (validate + tests + rollback plan)
• Job huntDaily block45m
• PD1Nightly 30 questions45m
• CommRecord the demo-video voiceover until it's smooth30m

First full timed mock, brutal review, and the one legacy topic (Visualforce) you haven't touched. Book the real exam today.

• PD1Know the blueprint + book the exam slot30m
  Blueprint (approx weights) + booking

  • Developer Fundamentals ~23% · Process Automation & Logic ~30% · User Interface ~25% · Testing, Debugging & Deployment ~22%. 60 questions, 105 min, pass 68%, proctored online or center.
  • Book via Webassessor (Kryterion) for Day 25, morning slot. Online-proctored needs: quiet room, webcam sweep, no second monitor.
  • Free official prep: Trailhead's "Prepare for Your Salesforce Platform Developer I Credential" trailmix — skim its unit quizzes tonight.
• PD1Timed mock #1 — 60 Q / 105 min, exam conditions2h
• PD1Review EVERY question — flashcard the misses2h
  Not just the wrong ones: also the "guessed right" ones. Each miss → one line in a flashcards note: claim + why. Score below 65%? Tomorrow's mock decides whether Day 25 stays an exam day or becomes a mock day — no shame either way, the interviews matter more than the badge date.
• TheoryVisualforce survival kit (it's still on the exam)1h
  Open theory — the 60-minute VF tour

  <apex:page standardController="Account" extensions="AccountExt">
      <apex:form>
          <apex:pageBlock title="Edit">
              <apex:inputField value="{!Account.Name}"/>
              <apex:commandButton action="{!save}" value="Save"/>
          </apex:pageBlock>
      </apex:form>
  </apex:page>

  • Standard controller = free CRUD for one record ({!save}, {!Account.Name}); extensions add custom Apex (constructor takes ApexPages.StandardController); fully custom controllers exist.
  • Expression syntax {!...}, apex:repeat / pageBlockTable for lists, rerender for partial refresh, ViewState = the serialized page state (the classic "why is my VF page slow" answer — too much state).
  • Where VF survives in 2026: renderAs="pdf" documents, email templates, a few legacy consoles. Everything new = LWC — say that with confidence.
• PD1Weak-area patch — 90 min on your two worst blueprint sections1.5h
• Job huntDaily block45m
• Comm2 explainers on today's flashcard topics30m

Second mock exam, then the dress rehearsal that matters: a full 60-minute technical interview, recorded.

• PD1Timed mock #2 + full review3.5h
  Target ≥ 75% (real exam feels 5 points harder than good mocks). Flashcard the misses. ≥ 70%? Green light for tomorrow. Below? Push the booking 3–4 days (Webassessor allows rescheduling) and convert exam day into mock day — decide now, not at 11 pm.
• MockFull 60-min technical mock interview — recorded1.5h
  The script (have a friend read it, or run it with Claude)

  1. "Introduce yourself" (2 min — rehearsed but human)
  2. "Walk me through your main project" (the capstone pitch + follow-ups: why events? why queueable? what breaks at 10× volume?)
  3. Rapid technical: order of execution · future vs queueable · wire vs imperative · governor limits you've hit · test a callout
  4. Scenario: "Nightly sync of 200k loan records from a core banking system — design it." (batch + upsert External Id + error handling + monitoring)
  5. "You don't have 5 years — why should we take you?" (the script from Reference, delivered calm)

  Watch the recording at 1.5×. Score: structure (skeleton used?), pace (silence beats "umm"), specificity (project references?). Fix the worst 5 answers by re-recording just those.

• PD1Final flashcard sweep — limits · OoE · async · sharing tables45m
  Tonight's read: Reference → Governor limits, Order of execution, Async table. Then STOP studying by 9 pm. Sleep is exam prep.
• Job huntDaily block — light: 5 apps + confirm interview logistics30m
• CommRe-record the 2 weakest mock answers45m
• PrepExam-day logistics — ID, room, webcam test, water15m
• PD1Last nightly questions — 20 easy ones for confidence30m

Take the exam. Then let the result work for you the same afternoon.

• PD1Morning review — 45 min, tables only, then stop45m
  Limits table, order of execution, async comparison, sharing ladder — read, don't cram. No practice questions today (they only shake confidence).
• PD1THE EXAM105m
  Pace: ~1.5 min/question, flag and move on, second pass for flags. Eliminate two wrong options first. Unanswered = wrong, so answer everything.
• Job huntPassed? Announce + surge. Didn't? Rebook + surge anyway.1.5h
  Both branches

  • Passed: LinkedIn post (template in Reference) — cert + capstone link in one post; add credential to resume/Naukri headline ("PD1 Certified"); message the 5 warmest recruiter contacts directly with the update. Then 15 applications riding the momentum.
  • Missed it: retake is $100 after 24h wait — book it for ~Day 29 now, log the section scores into the flashcard file, and do the 15 applications anyway. The capstone + interview skills were always the main bet; the cert is a booster, not the rocket.
• Comm1 explainer — "what I'd tell someone taking PD1 tomorrow"15m
• RestTake the evening off — deliberately—
  Five days of interview drilling start tomorrow. Recovery is part of the plan, not a break from it.

Five-year interviews are won in the scenario round. Today you rehearse the 15 designs that cover 90% of what gets asked.

• DrillThe 15 scenarios — answer aloud with the design skeleton3h
  Scenarios + approach hints (hide hints on first pass)

  1. Nightly sync of 200k records from core banking. (Batch + upsert External Id + partial-success logging + monitoring + reconciliation report)
  2. Users hit UNABLE_TO_LOCK_ROW during mass updates. (contention on parent; FOR UPDATE, retry with backoff, serialize via queueable, reduce parent touches)
  3. "A user can't see a record." (the sharing debug ladder, verbatim)
  4. Real-time notification to an external app when opportunity closes. (Platform Event / CDC + subscriber; why not callout-from-trigger)
  5. Trigger works for one record, fails on Data Loader. (bulkification story + how you'd find it: debug logs, limit usage)
  6. Approval needed from an external compliance system before case closes. (validation blocks close until flag; queueable callout on submit; PE on response flips flag)
  7. Duplicate customers keep appearing from three intake channels. (normalize + dedupe trigger, duplicate rules, upsert External Id per channel, survivorship rules)
  8. The org hits SOQL 101 in production after a release. (find the loop query — logs/limits, fix, and the process answer: PR review + bulk tests would have caught it)
  9. Design the household total-balance rollup — FSC edition. (RBL if package available; else your Apex rollup pattern; discuss recalcs and skew)
  10. Millions of financial accounts — a report times out. (LDV: selective filters, indexes/skinny-table name-drop, summary object updated by batch, archive strategy)
  11. Screen flow or LWC for the account-opening wizard? (flow for speed/admin ownership; LWC for UX control/complex validation — argue both, pick one, justify)
  12. A managed-package trigger conflicts with yours. (no order guarantee; make yours idempotent/defensive, bypass switches, log and isolate)
  13. Sandbox-to-prod deploy failed on missing coverage. (test levels, the fix, and the prevention: CI validate on PR)
  14. Batch job overlaps its previous run. (check AsyncApexJob for running instance before executeBatch; or chain from finish)
  15. PII fields must be hidden from most users but used in code. (FLS + permission sets; without sharing service with stripInaccessible on the way out; audit)

  Skeleton for every scenario: clarify assumptions (volume? real-time?) → name the pattern → walk the happy path → failure handling → limits check → "in my capstone I did the smaller version of this."

• CommSTAR bank — write and rehearse all 81.5h
  The 8 stories (90 seconds each)

  1. Hardest bug of the month (KYC retry? LMS wiring?) — Situation, Task, Action, Result with a number
  2. Learned something fast under pressure (this entire month — frame one week of it)
  3. A time you were wrong and corrected course (a design you reversed — flow→apex or vice versa)
  4. Conflict/disagreement handled (from any past job/college — genuine beats impressive)
  5. Deadline you protected (Day-25 exam pipeline while interviews ran)
  6. Feedback you acted on (your comm recordings improving — meta but true and memorable)
  7. Something you're proud of (the capstone demo)
  8. Failure that taught you (pick real; rehearse the recovery half harder than the failure half)
• BuildCapstone pitch v2 — 3-min + 10-min deep-dive versions1h
  3-min: problem → architecture → one wow (live SLA or event decoupling) → stack list. 10-min: screen-share walkthrough with code stops at the trigger framework, the queueable+finalizer, and the wizard. Rehearse both twice.
• Job huntDaily block + chase every silent application from Week 245m
• DrillRandom-fire round — 20 questions from the master bank45m
  Open Reference → Question bank, pick randomly, answer in skeleton form. Mark any stumble for tomorrow's mock.
• CommRecord the 3-min pitch until one take is clean30m

Simulate the real gauntlet: technical, scenario, HR — back to back, scored against a rubric, weakest answers rebuilt same day.

• MockRound 1 — technical (60 min)1h
  Interviewer (friend/Claude/self-script): 15 questions across weeks 1–3, two "write this on screen" moments (bulkified trigger skeleton; wire+imperative component skeleton). Recorded.
• MockRound 2 — scenario/architecture (45 min)45m
  5 scenarios from yesterday's 15, but with pushback ("what if volume is 10×?", "why not CDC?"). Holding your ground politely IS the skill being tested.
• MockRound 3 — HR/behavioral (30 min)30m
  Intro · why Salesforce · why this company · the 5-years question · salary expectation (band, not number — script in Reference) · notice period · 2 STAR stories · "questions for us?" (always have 3).
• ReviewScore all three + rebuild the worst 5 answers1.5h
  Rubric per answer (1–5): structure · correctness · specificity (project-anchored?) · pace. Anything ≤ 3 gets rewritten as bullets and re-recorded tonight.
• Job huntDaily block45m
• PD1(If retaking) 30 questions on weak sections45m

Everything cloud-specific gets one final varnish: models redrawn, FSC scenarios rehearsed, JS sharp for LWC rounds.

• DrillRe-whiteboard all three models + record 3-min narrations1.5h
  Product chain · entitlement model · FSC household. Compare tonight's recordings with Day 21's — they should be noticeably tighter.
• DrillFSC scenario set1.5h
  The 8 FSC scenarios

  1. Design household total-deposits with and without RBL
  2. One person in two households — model it (ACR roles)
  3. Advisor leaves — reassign book of business (ownership + shares + open items)
  4. Only the deal team may see interaction notes (CDS / participant roles)
  5. Auto-create onboarding Action Plan when household forms (your Day-19 flow, narrated)
  6. KYC flag from an external bureau must gate account opening (your capstone!)
  7. Migrate 500k legacy financial accounts in (Bulk API + upsert External Id + batch validation)
  8. Person account vs individual model — a bank asks which; advise
• TheoryJS brush-up for LWC rounds1.5h
  Redo the Day-12 survival kit from memory in a blank JS file: write map/filter/reduce, a debounce, a Promise.all, an async/await with try/catch. Stumbles = tonight's drill topics.
• DrillRandom-fire — 25 questions from the master bank1h
• Job huntDaily block45m
• Comm3 × 2-min — the three models, final versions45m

One continuous end-to-end interview simulation, then everything around the interview gets professionalized.

• MockThe full simulation — 2h continuous, recorded2h
  Intro → 3-min pitch → 40 min technical → 30 min scenario → 20 min HR → your questions. No pauses, no restarts — build the stamina real loops demand.
• PrepLogistics kit1.5h
  The kit

  • Questions to ask them (pick 3): "What does the first 90 days look like for this role?" · "How is work split between config and code on your projects?" · "What's the team's deployment pipeline?" · "What would make someone exceptional in this seat by month six?"
  • Salary: research your city's band for 1–3 yr SF devs (peers, Glassdoor, recruiter asks); answer as a band + "flexible for the right learning curve." Never a single number first.
  • Notice period / availability: one honest sentence, rehearsed.
  • Video setup: camera at eye level, light in front, phone on silent, capstone org logged in + demo tab ready in background for the "can you show me?" moment.
  • The gap script, final version — say it once more to the mirror: JD asks 5 years → "here's the stack, here's my build on exactly that stack, test my depth anywhere."
• ReviewWatch the simulation, fix top 3 issues1h
• Job huntDaily block + schedule next week's interview slots smartly (warm-ups first)45m
• PD1(If retake booked) final review45m
• CommWatch Day-1 recordings vs today's — write down 3 differences30m
  This is the confidence deposit you'll draw on in real interviews: proof, on video, that you improve fast.

The sprint ends; the campaign continues. Today maximizes surface area while everything is sharp.

• Job huntApplication surge — 20 applications + 10 referral DMs2.5h
  Refresh Naukri first. Target list: big SIs + mid-size Salesforce shops + FSC specialists (search "Financial Services Cloud developer" on LinkedIn to find them). Log everything.
• PublishLinkedIn capstone post — the demo video goes public45m
  Template in Reference. Video + 5 lines + repo link + honest framing ("30 days ago I decided to go deep on Salesforce development…"). Posts like this get recruiters DMing YOU.
• CommunityJoin the pipeline that isn't a job portal45m
  Trailblazer Community group for your city (join + introduce yourself), find the next Salesforce Saturday / meetup and RSVP, follow 10 FSC/SF-dev voices on LinkedIn and comment substantively on 2 posts.
• RetroGap list + 2-week maintenance plan1h
  The maintenance loop (until offer)

  • Daily (2h): 45m random-fire drills · 45m job hunt · 30m comm rep (one explainer or one answer re-record).
  • Alternate days: one full mock OR one capstone enhancement (ideas: Agentforce experiment, batch reconciliation report, JS Developer cert prep — pick from your gap list).
  • After every real interview: same-day debrief — every question you fumbled becomes a flashcard + a re-recorded answer within 24h. Real interviews are your best training data now.
  • Weekly: re-read this dashboard's Reference tab once, cover to cover — 30 minutes keeps everything warm.
• CommFinal recording — "Day 30: my 3-minute story"30m
  Watch Day 1's video first. Then record the person you are now. Keep both forever.
• DoneMark the sprint complete — and keep the daily loop alive—