Technical Communication and Decision Making Questions

Focuses on the ability to explain technical solutions, justify trade offs, and collaborate effectively across engineering and non engineering stakeholders. Topics include articulating design decisions and their impact on reliability performance and maintenance, walking through solutions step by step, explaining algorithmic complexity and trade offs, asking clarifying questions about requirements, writing clear comments documentation bug reports and tickets, conducting and communicating root cause analysis, participating constructively in code reviews, and negotiating quality versus delivery trade offs with product and operations partners. Interviewers evaluate clarity of expression, reasoning behind decisions, and the ability to make choices that balance short term needs and long term quality.

EasyTechnical

60 practiced

Write an example 'What changed' and 'Why' summary for a PR that refactors user authentication, introduces a backward-incompatible session token format, and requires a short migration. The summary should be concise for reviewers and ops, list migration steps, and call out risks and rollback steps.

HardTechnical

53 practiced

Two engineering teams disagree about adopting a shared stateful service versus separate services for their domains. As a senior full-stack developer, describe how you would facilitate a decision: what data to gather, which workshops to run, the decision framework you would use (e.g., decision matrix), and how to document and communicate the final decision including rollback criteria.

MediumTechnical

57 practiced

You maintain a public REST API used by multiple internal teams and need to introduce a breaking change. Draft an announcement email and migration checklist for consumers that includes the change description, example requests and responses, migration steps, timeline for deprecation, rollback policy, and available support channels.

Sample Answer

**Subject:** API v1 -> v2 Breaking Change: /orders endpoint — Action Required

**Announcement (email body)**Hi all — we’re releasing a breaking change to the public REST API: /orders will move from returning line-item arrays to a normalized items object and require Authorization: Bearer token with scope orders:write for POST. This improves consistency and reduces payload size.

Key change- Old: "line_items": [{ "id": 1, "qty": 2 }]- New: "items": { "1": { "quantity": 2 } }- POST now returns 202 Accepted with location header for async processing.

Example requests/responses- GET old response:

json

{ "order_id": 123, "line_items": [ { "id": "1", "qty": 2 } ] }

- GET new response:

json

{ "order_id": 123, "items": { "1": { "quantity": 2 } } }

- POST example:

bash

curl -X POST https://api.example.com/v2/orders \
 -H "Authorization: Bearer <token>" \
 -H "Content-Type: application/json" \
 -d '{ "items": { "1": { "quantity": 2 } } }'

**Migration checklist**1. Update client payloads to send "items" object and map quantity field.2. Update parsing logic that expects array -> adapt to object keys (Object.entries or equivalent).3. Add retry/async handling for 202 + Location header.4. Ensure token includes orders:write scope; update auth flow if needed.5. Run integration tests against staging v2 endpoints.

**Timeline**- Announcement: today- SDKs & docs updated: 2 weeks- Deprecation start (v1 read-only): 6 weeks- v1 removed: 12 weeks

**Rollback policy**- We will monitor errors; if critical failures appear within 48 hours of release we will rollback v2 to read-only and re-enable v1 write endpoints while patching. Emergency rollback will be communicated and applied within 4 hours.

**Support**- Primary: #api-issues Slack (mon–fri 09:00–18:00 UTC)- Pager: on-call (for critical incidents)- Email: api-support@example.com- Weekly office hours: Wed 15:00 UTC for migration help

If you want a migration PR template or a helper mapping function (JS/Python), I can provide one.

MediumBehavioral

70 practiced

Describe a plan for mentoring a junior developer through a large pull request that contains functional mistakes and style issues. Include the exact kinds of comments you would leave, when you'd ask to pair-program, how you'd balance teaching with shipping needs, and how you'd preserve the mentee's confidence.

Sample Answer

**Situation & Goal** I mentor a junior full‑stack dev who submitted a large PR with functional bugs and style issues. My goal: fix production risk quickly, teach durable skills, and keep their confidence.

**Plan (Steps)** 1. Triage & prioritize- Leave a top-level comment: "Thanks — I’ll help split this into critical fixes vs. polish. I’ll mark urgent issues below." - Create checklist labels in PR for: Blocker (bug), Tests missing, Styling, Refactor.

2. Targeted review comments (examples)- Functional bug: "Line 142: when user has no orders, this returns null and crashes render. Suggest: check orders?.length and add fallback UI. Example: if (!orders || orders.length === 0) return <EmptyState />."- Logic clarity: "Can you extract this map+filter into a named helper (getActiveSessions)? It’ll be easier to test."- Style/consistency: "Prefer our ESLint rule: use === instead of ==. Please run `npm run lint -- --fix`."- Tests: "Add unit tests for the edge case when API returns 500 — see tests/session.test.js for pattern."

3. Pair-program triggers- I ask to pair when: a) complex state/async bug spans frontend/backend, b) they seem stuck >30–45 minutes, or c) refactor affects authentication flow. Comment: "Would you pair on Tuesday 10am to walk through the auth flow and fix this race condition together?"

4. Balance teaching vs. shipping- Patch critical bugs myself with annotated commits for speed, while assigning nonblocking refactors back to them with milestones. Use feature toggles for risky changes.- Example: "I pushed a hotfix commit to prevent crash (explained in commit message). Please implement the recommended helper and tests in the next PR."

5. Preserve confidence & growth- Start with positives: "Nice test coverage for the API mapping — shows good end‑to‑end thinking." - Use guiding questions, not accusations: "What did you consider for X?" - End with clear next steps and offer follow-up pairing: "Great work — once these changes are in I’ll review again and we can pair on writing the missing tests."

Result: faster recovery from bugs, clear learning moments, and the mentee feels supported and ownership retained.

MediumTechnical

60 practiced

Explain SLOs, SLIs, and SLAs to a non-technical product manager in plain language. Then propose three SLIs for an e-commerce checkout service (with suggested thresholds and measurement windows), and briefly justify why those SLIs map to business risk and user experience.

Unlock Full Question Bank

Get access to hundreds of Technical Communication and Decision Making interview questions and detailed answers.

Join thousands of developers preparing for their dream job.