Interview Playbook

“Doing well — good busy. Just wrapped a sprint review this morning, so the timing's perfect. How's your day going?”

“Pretty great, actually — we shipped a phase to UAT this week, so I'm riding that. How about you?”

(Early call) “Doing well — I'm on the West Coast so you've caught me on my first coffee, but it's working. How are you?”

“I did — I noticed you [rebuilt the storefront on X / focus on Y vertical / just announced Z]. It actually made me curious about [genuine question] — maybe we'll get to that.”

“Well — I'm excited to dig in. Where would you like to start?”

(If they outline the structure, echo it back:) “Perfect — background first, then technical, then my questions. Let's do it.”

“This was a great conversation — I especially appreciated the transparency about [something real they said]. What are the next steps, and what's your timeline?”

(If it went well and you want it:) “I'll say it plainly — this sounds like a problem I'd enjoy owning. I'm interested.”

“My current engagement is project-based, and the major phase wraps up soon — so the timing is natural. I'm looking for CHECK: your real driver — scope / stability / product home. I'm not running away from anything; I'm choosing the next thing deliberately.”

“I'm in the Vancouver, BC area, Pacific time zone, and I work remotely with distributed teams daily — my current teams span North America and Europe. CHECK: your exact line for US roles — citizenship/PR status; C2C via Enum Solutions Inc. for contracts; W2 position”

“I'd rather understand the full scope first — but so we don't waste each other's time, what range is budgeted for the role?”

“CHECK: FTE base range for employment, or CHECK: hourly rate on contract, depending on scope and term.”

“CHECK: e.g. 'I can start within two weeks; I'd want to hand my current project off cleanly.'”

“Deep, hands-on: Sales Cloud, Service Cloud, Experience Cloud, and Consumer Goods Cloud / Trade Promotion Management. I've built with Platform core — Apex, LWC, Flows, integrations — for eight years. I've worked around CHECK: honest level for Data Cloud / Marketing Cloud / CPQ at the design level. And I'm certified PD I, PD II, and App Builder.”

“Right now I do run more than one project — that's consulting life — but it's managed, not chaotic: each project has tracked hours and a sprint budget, so allocation is a planning decision, not a daily scramble. Overtime for me is the exception with a named reason — a release week, an incident — never a lifestyle. Honestly, part of the appeal of this role is CHECK: tailor — 'focusing deeper on fewer things' for FTE roles / 'a clearly-scoped engagement' for contracts. What does the typical load look like on your side — how many projects would this role touch at once?”

“My hands-on Data Cloud time is CHECK: honest amount. What I do have is deep data-migration methodology from pharma, automotive, and TPM projects — and Data Cloud migration is a data-architecture problem before it's a product problem: map the source data model to the DMOs, define the identity-resolution strategy — which keys unify a person across sources, in what precedence — then a phased cutover: parallel run, reconciliation counts on every object, checksum spot-samples, and business-user validation on named scenarios before you flip. I ramp fast on product specifics; the methodology is what fails migrations, and that I own.”

“Standards plus autonomy. I set the guardrails explicitly — coding standards, definition of done, the escalation path — and then give people real ownership inside them. I run small teams with clear per-person task ownership, everything tracked against records so status is visible without me asking. I'm hands-on enough to review every PR that matters, but the goal is that the team doesn't need me in the loop for routine decisions. One concrete habit: my teams have a rule that if you're blocked and I haven't responded in two hours, you escalate — Slack first, then email, then grab anyone who can unblock you. Blockers don't get to age quietly.”

S: “On one of my project teams, a developer kept pushing changes that skipped the review-and-test gate we'd agreed on — fast work, but twice it broke the shared sandbox and cost the team half a day each time.

T: As the lead I owned both the standard and the relationship — the behavior had to change without losing a productive developer.

A: Private, fast, specific — same week, one-on-one. I separated the person from the pattern: 'your output is strong; this habit is taxing the team — here's the incident and what it cost.' I asked for their side first — they felt the pipeline was slow, which was half-true. So we made a deal: they follow the gate, I fix the pipeline pain point. And I made the standard visible for everyone so it wasn't personal.

R: The behavior stopped, the pipeline got faster for everyone, and that developer later became one of the people enforcing the standard in reviews.”

“Three habits. First, decomposition and estimation up front — I break work down until each estimate is honest, and I involve the people who'll do the work. Second, visible tracking against a budget — my current projects run sprint-by-sprint with hours and spend tracked weekly against plan, so drift shows up in days, not at the deadline. Third — the one most people skip — scope discipline: when requirements evolve mid-project, that becomes a named change order with its own estimate, not silent absorption. Timeline problems are almost never velocity problems; they're unmanaged-scope problems. And I plan for people, not just tasks — before I take two weeks off, the UAT environment is deployed, coverage is assigned by name, and the client knows the protocol.”

“I stop asking for requirements and start asking for outcomes. Nontechnical clients can't give you requirements — that's my job — but they're the world's best experts on their own process and pain. So I ask them to walk me through how they work today, where it hurts, and what 'done' would look like in their words. Then I translate: I bring back mockups, diagrams, or a clickable prototype — something they can react to, because people are far better at correcting something concrete than specifying something abstract. I restate what I heard in their vocabulary, not mine, and I keep a shared living document — the client sees the list, the status, and what was agreed. Cheap iterations early; the expensive mistake is building the wrong thing correctly.”

“Recent example: a customer-facing Experience Cloud portal built with Lightning Web Components for a major food brand — content-heavy, marketing-driven, with file and data integration from Microsoft Dynamics behind it.

Hurdles: cross-system integration first — Dynamics and Salesforce disagree about data shape, so we nailed the contract and tested both sides against a dedicated dual-test sandbox. Second, dependency on client-side assets — marketing imagery arrived late and could have stalled the timeline, so I decoupled: we built against placeholders and made asset delivery a tracked client-side item, visible on the plan — the delay was theirs to own and ours to absorb without drama.

Scope control: a shared testing document both sides worked from — every issue logged, statused, retested; nothing entered the build from a hallway conversation. When feedback threatened the end date, we renegotiated the date explicitly rather than silently crunching.

Result: CHECK: phase delivered; timeline extended once by agreement; phase 3 followed.”

S: “[Production integration between Salesforce and the client's ERP stopped syncing — orders piling up, business-visible within hours.]

T: [I owned the integration design, so I owned the fix.]

A: First move in any incident: stop the bleeding before finding the cause — [pause the job so bad data doesn't compound], and communicate a status and ETA to the client immediately; silence is what actually damages trust. Then diagnosis: [logs → recent changes → culprit: upstream schema change / API-limit exhaustion / record-locking conflict]. Fix, verify with a reconciliation pass, then the part most people skip — the postmortem: [monitoring and alerting added so this class of failure pages us before the client sees it].

R: [Restored in N hours, no data loss; the new monitoring caught two later issues before anyone noticed.] Incidents are a trust opportunity — clients remember how you communicate during a fire longer than the fire itself.”

“Both, honestly, and I've alternated. I've been the autonomous end-to-end person — design, build, deploy, support — and I've led a team of eleven and directed a managed-services group. Right now I lead a small distributed dev team day to day: assigning work, reviewing PRs, coordinating with PMs and the client. So a team-coordination-heavy role isn't a change for me — it's the mode I'm in. And the solo years made me a better lead, because I never assign work I couldn't do myself.”

“The frame I use: never 'no', always 'here's what that costs.' When a client asks for something that's a bad idea or off-scope, I don't argue in the meeting — I say 'we can do that; let me bring you what it means' and come back with options: impact on timeline, budget, and risk, plus an alternative that gets 80% of the value for 20% of the cost. The client stays the decision-maker — I'm just making the decision honest. People don't get defensive when you give them options; they get defensive when you tell them they're wrong.”

“I've written the standards docs at two companies, so I have opinions. The short version for Salesforce: one trigger per object with a handler framework — logic never lives in the trigger. Separation of concerns — service layer for business logic, selector layer for queries, thin controllers. Everything bulkified as a default, never as an afterthought. Naming that reads as documentation. Static analysis in the pipeline — PMD / Salesforce Code Analyzer, ESLint and Prettier on the LWC side — so style debates happen with a linter, not in code review. Code review on everything; the standard applies to me too. And the meta-rule: a standard that isn't enforced by tooling or review isn't a standard, it's a wish.”

“Tests are executable specifications, not a coverage score. Salesforce forces 75% coverage, which creates a culture of coverage theater — tests with no asserts that exercise code without verifying anything. I reject that: every test asserts behavior, including the negative paths and the bulk path — 200 records, not one. Test data comes from factories, never SeeAllData. Unit tests isolate logic — which is why the service/selector separation matters: you can mock the data layer. Integration-level flows get tested in a dedicated sandbox against realistic data, and it all runs in CI on every merge — a test that only runs when someone remembers doesn't exist.”

“Yes — it's the answer to 'my coverage is high, but is it testing anything?' You introduce small mutations into the code — flip a condition, change an operator — and rerun the suite. If the tests still pass, they weren't asserting that behavior: the mutation survived. It measures assert quality, where coverage only measures execution. It's not common in the Salesforce world CHECK: mention if you've run PIT / Stryker, but the principle drives how I review tests: I read the asserts, not the coverage number.”

“VS Code with the Salesforce extensions and the sf CLI. Git — GitHub and GitLab, both of which I've built CI/CD on. Pipelines: CHECK: your current CI — GitLab CI / GitHub Actions, sfdx-project based, with static analysis and test gates. Jira and the Atlassian suite for delivery. Postman for API work. Middleware on integrations — Boomi on my current project. And a heavy AI-assisted layer on top, which I suspect you'll ask about.”

“Daily and deliberately, in three tiers. First, code: AI drafts boilerplate, test classes, migration scripts, and does a first-pass review before a human sees my PR — a very fast junior developer whose work I always review; nothing AI-generated ships unread. Second, delivery: meeting summaries, status drafts, documentation — the overhead that used to eat architect time. Third — the interesting one — automation: I build agent-based workflows that handle recurring processes end to end CHECK: examples you'll share — job-queue automations, internal AI tooling. And the guardrails matter: client data stays inside approved tools, and AI output gets verified before it's used. The productivity gain is real — the review discipline is what makes it safe.”

“CHECK — fill from memory before interviews: The [pharma / automotive] project: ~N custom objects, ~N Apex classes, N integrations, team of N across N countries, N-month timeline. What made it large wasn't the object count — it was [the coordination surface: multiple teams shipping into one org / regulatory constraints / integration contracts].”

“Salesforce is rarely alone in my projects. Currently: Salesforce TPM integrated with the client's ERP for master data and actuals, Dynamics feeding files and data into Salesforce for the portal project, middleware — Boomi — handling transport, plus outbound integrations for promotions data. Past: the automotive distributor — Salesforce to CHECK: edge systems; at Telinta, a whole VoIP billing ecosystem with custom portals, payment gateways, and a WebRTC layer. I default to treating Salesforce as one system in a landscape, with explicit contracts at every boundary.”

“AI agent orchestration. Not just using a chat assistant — building multi-step agent workflows: scheduled jobs that read my inbox and queue work, skills that encode my repeatable processes so an agent can run them, tool-calling pipelines against real APIs. I did it to automate my own overhead, but it's become a real professional skill — it changed my estimate of what one engineer can own. CHECK: add other current learning — Data Cloud path, TypeScript, …”

“JavaScript, with caveats — it's the language I've used longest, from browser extensions to WebRTC to LWC, and modern JS/TypeScript is a pleasure. Apex I respect as a workhorse: Java's less exciting cousin, but predictable — and the platform guarantees around it are the point. Honest answer: my favorite language is whichever one has the best tooling for the problem in front of me. CHECK: swap if your real answer differs”

“Two things — one technical, one human. Technical: the CI/CD pipeline on the automotive project — it cut development costs by about 40%, and pipelines I built at Avenga outlived my tenure across multiple teams. Systems that keep paying after you leave are the best kind of work. Human: the developers I've trained. I ran technical training and workshops at Avenga, wrote the standards people learned from, and some of the developers I mentored now hold senior roles. CHECK: name a specific person/outcome if you have one”

“One thing that doesn't fit neatly on the resume: I've kept a rare combination — architect-level design responsibility while staying genuinely hands-on, including modern AI-assisted development. Teams I lead get someone who can draw the diagram, defend it to the client, and then sit down and build the hard part. That's what I'd bring here.”