Leadership, Coding & Communication

Make staff-level scope visible

A senior answer is not made senior by saying “I led.” It becomes senior when the interviewer can trace how you framed an unclear problem, changed a consequential decision, created leverage beyond your own code, and verified the result.

The six-story portfolio

Prepare one story for each row. A story may cover more than one row, but do not force every question into the same heroic project.

Use STAR-L, but keep the “A” inspectable

Situation gives only the context needed to understand the stakes. Task names your mandate and constraints. Action should consume roughly half the answer: questions asked, analysis performed, options rejected, people aligned, safeguards added, and course corrections. Result separates measured outcomes from impressions. Learning says what you would repeat or change.

Lead decisions, not meetings

Influence without authority comes from improving the decision environment. Make the problem legible, expose trade-offs, invite the right objections, and leave a durable record.

A compact architecture decision record

Title: Choose the retrieval serving path
Status / owner / decision date:
Context: users, scale, sensitivity, current failure
Decision drivers: quality, p95 latency, cost, operations
Options: A / B / C, with evidence and migration effort
Decision: chosen option and why now
Consequences: gains, accepted debt, new risks
Rollout: shadow → limited cohort → broader release
Rollback and revisit triggers:

The record is not a ceremony. It is a compression mechanism: a teammate in another time zone should be able to challenge or execute the decision without reconstructing a meeting.

Resolve disagreement with a ladder

1. Restate the shared objective and the other position until its owner agrees.
2. Classify the disagreement: facts, forecasts, values, constraints, or ownership.
3. Seek disconfirming evidence and define a time-boxed test when the decision is reversible.
4. Ask the accountable owner to decide when evidence cannot remove uncertainty.
5. Disagree, commit, and log a revisit trigger rather than relitigating continuously.

Write so work can continue without you

Current Remote and Sourcegraph role pages explicitly emphasize structured writing, async work, customer communication, autonomy, and substantive review. Treat writing as part of system reliability: missing context creates coordination failures just as missing timeouts create runtime failures. See the live Remote Senior Forward Deployed Engineer role and Sourcegraph Agent Engineer role.

The five-block async update

Outcome: what changed for the user or project
Evidence: test, metric, trace, screenshot, or decision
Risk: what could still invalidate the result
Next: owner and date for the next concrete action
Ask: one explicit decision or help request, if needed

Lead with the outcome, not an activity diary. Replace “worked on evaluation” with “the release gate now catches the three known citation regressions; the multilingual slice is still below its proposed threshold.”

Design memo anatomy

A two-page memo should cover problem and non-goals, users and success measures, constraints and assumptions, proposed flow, alternatives, failure modes, security, operations, rollout, and unresolved questions. Put the recommendation near the top. Attach detailed benchmarks rather than burying the decision beneath them.

Code-review comments that create leverage

Tag the nature of the comment: blocker for correctness or safety, important for maintainability, suggestion for a worthwhile alternative, and nit for optional polish. State the consequence and, where useful, a concrete path forward. Google’s engineering review guide and GitHub’s pull-request review documentation are useful primary references for review practice and review states.

Translate trade-offs for customers

Use consequence language. “A reranker adds another model call” is technical description. “A reranker may improve the difficult queries we sampled, but adds latency and cost to every request; we propose enabling it only for low-confidence queries and measuring both task success and p95 latency” is a decision a customer can evaluate.

Make coding reasoning observable

Senior coding screens still require fundamentals, but the strongest signal is controlled problem solving: establish the contract, choose the simplest correct structure, prove the invariant, and test the boundaries.

The 40-minute loop

1. Clarify: input size, ordering, duplicates, empty values, mutation, return contract, and error behavior.
2. Example: walk one normal case and one adversarial case by hand.
3. Baseline: give a correct simple approach and its time/space cost.
4. Pattern: choose map/set, two pointers, sliding window, stack, heap, binary search, traversal, backtracking, greedy, or dynamic programming because a specific invariant fits.
5. Implement: name state by meaning and narrate only consequential choices.
6. Verify: trace edges, state complexity, and identify what would change at production scale.

Practise the work-shaped screens

The syllabus calls out async Python, SQL, APIs, transformations, tests, unfamiliar code, and reading Go or TypeScript. These exercises reward production instincts more than puzzle tricks.

Async Python: concurrency needs ownership

import asyncio

async def fetch_all(ids, fetch_one):
    async with asyncio.TaskGroup() as group:
        tasks = {item_id: group.create_task(fetch_one(item_id))
                 for item_id in ids}
    return {item_id: task.result() for item_id, task in tasks.items()}

TaskGroup gives the subtasks a lifetime owned by the context. Discuss timeouts, bounded concurrency, partial-result policy, and cancellation cleanup; the Python documentation explains that task-group failure cancels remaining tasks and that cleanup should propagate cancellation after finally work. Read the official coroutines and tasks documentation.

SQL: express the business question first

WITH ranked AS (
  SELECT tenant_id, run_id, cost_usd,
         row_number() OVER (
           PARTITION BY tenant_id ORDER BY cost_usd DESC
         ) AS cost_rank
  FROM agent_runs
  WHERE started_at >= :window_start
)
SELECT tenant_id, run_id, cost_usd
FROM ranked
WHERE cost_rank <= 3;

This asks for the three most expensive runs per tenant, not the three most expensive globally. Explain tie semantics (row_number versus rank), indexes supporting the filter, and why an execution plan matters. Use the official PostgreSQL guides to window functions and EXPLAIN.

API implementation checklist

• Validate request shape and semantic constraints; return stable error contracts.
• Derive identity and tenant scope from authentication, not caller-supplied fields.
• Define idempotency, timeout, retry, concurrency, and transaction boundaries.
• Test happy path, malformed input, duplicate request, dependency timeout, and forbidden access.
• Expose correlation identifiers and useful telemetry without logging secrets.

Debugging unfamiliar code

Restate the symptom, bound the blast radius, reproduce with the smallest input, trace data across boundaries, and form ranked hypotheses. Change one variable at a time. A senior candidate distinguishes mitigation from root-cause correction and adds a regression test plus a detection improvement.

AI-assisted code is still your code

Record the prompt or intent when relevant, inspect every changed line, verify dependencies and licenses, threat-model new data paths, run targeted and broader tests, and be ready to explain the result without the assistant. Current Sourcegraph and Automattic application material asks candidates for concrete opinions about coding agents; speak from a real workflow, while never presenting generated code as independently trustworthy.

Syllabus checkpoint: complete coding-pattern coverage

Keep a compact mental map rather than memorizing isolated solutions. Arrays and strings reward index discipline, maps/sets capture membership and counts, and two pointers or sliding windows exploit ordered or contiguous structure. Stacks model nested or monotonic state; queues model FIFO work; linked lists test pointer ownership and edge cases. Binary search needs a monotone predicate, while interval problems require explicit boundary semantics.

Trees and graphs share traversal machinery but different invariants: tree DFS supports subtree/postorder reasoning, BFS supports levels and minimum unweighted hops, and general graphs require cycle/visited handling. Heaps maintain an extremum or top-k frontier. Backtracking explores a choice tree with pruning; greedy algorithms require an exchange or staying-ahead argument; dynamic programming requires a state that contains all information future choices need. For every pattern, explain correctness, time/space complexity, empty/singleton/duplicate cases, and how you would test it.

Interview playbook

Choose the framework that matches the signal being tested, then keep the answer evidence-led.

Leadership answer: Scope → Judgment → Leverage → Evidence → Learning

1. Scope: users, stakes, constraints, your mandate, and what was ambiguous.
2. Judgment: alternatives and the pivotal decision, including what you rejected.
3. Leverage: how you aligned people or created a pattern others could use.
4. Evidence: measured result, rollout observation, or honest qualitative outcome.
5. Learning: a specific correction you would make next time.

Coding answer: Contract → Baseline → Invariant → Code → Tests → Cost

Clarify the contract, state a correct baseline, name the invariant behind the better approach, implement, trace tests, then give time and space complexity. Mention production concerns only after solving the asked problem.

Common traps

• Using “we” throughout so the interviewer cannot locate personal ownership.
• Claiming consensus when a real decision owner or disagreement existed.
• Giving activity metrics instead of an outcome or risk reduction.
• Narrating every keystroke during coding instead of decisions and invariants.
• Ignoring cancellation, authorization, duplicates, or failure behavior in practical tasks.
• Claiming AI assistance made work faster without showing verification or a quality boundary.

Question bank

Answer aloud. Keep leadership answers near two minutes initially; allow follow-up probes to reveal the deeper evidence.

Proof artifact: the senior-signal packet

Create one reviewable packet that combines leadership, writing, implementation, and explanation. Use a real project only where you can disclose it; otherwise build a clearly labeled sandbox case.

Build it

1. Choose a decision such as adding a reranking stage to a multi-tenant RAG service.
2. Write a two-page design memo and one ADR with criteria, alternatives, security, operations, rollout, rollback, and revisit triggers.
3. Implement a small async API plus a SQL report. Add tests for invalid input, timeout, cancellation, duplicate requests, and cross-tenant access.
4. Request or simulate review; classify comments and record which feedback changed the design.
5. Prepare a two-minute leadership account that states personal ownership without inventing project results.

Measure it

• Memo: decision visible in the first 200 words; every risk has an owner or acceptance statement.
• Code: test pass rate, branch coverage for critical failure paths, static checks, and p50/p95 latency under a declared load.
• Communication: a reviewer can state the decision, main trade-off, and next action after one read.
• Practice: solve and explain the coding task within a fixed time; log clarification, implementation, and verification minutes separately.

If you need numbers before measurement, label them as targets. For example: “hypothetical target: p95 below 800 ms at 20 requests/second,” never as a achieved result.

Inject failure deliberately

Make one downstream call exceed its timeout, send the same idempotency key twice, cancel the client request mid-flight, and attempt a cross-tenant identifier. Verify cleanup, stable error behavior, one durable side effect, and useful trace context. Then seed an AI-generated implementation with a subtle missing tenant predicate and demonstrate that review or tests catch it.

Present it

Bring the memo, ADR, small repository, test report, one trace, review log, and a ten-minute recording. Present the decision in two minutes, code invariant in two, failure evidence in three, and learning in one; reserve two minutes for questions.

Chapter review

Leadership is decision quality plus leverage. Coding is a visible chain from contract to proof. Remote communication is successful when another person can decide or act without recovering missing context.

Glossary

ADR

A short, durable record of an architecture decision, its context, consequences, and revisit conditions.

Invariant

A property that remains true while an algorithm progresses and supports its correctness argument.

Leverage

An intervention that improves the output or judgment of people beyond the author’s own task.

Structured concurrency

A model in which concurrent tasks have explicit ownership and bounded lifetimes.

Revisit trigger

Observable evidence that should cause a prior decision to be re-examined.

Window function

A SQL calculation across related rows while retaining each input row.

Mastery checklist

• I have six distinct, truthful stories with personal actions and defensible evidence.
• I can name the decision owner, rejected option, and revisit trigger in each architecture story.
• I can write an outcome-led update and a two-page memo without a meeting transcript.
• I can distinguish blocker, important, suggestion, and nit review feedback.
• I can solve representative map/window, graph, heap, and basic DP problems while explaining invariants.
• I can reason about async cancellation, SQL ties, API idempotency, authorization, and failure tests.
• I can explain exactly how I verify AI-assisted code.