Mid Level Career Progression Questions

Personal narrative focused on progression to and performance at mid level roles, typically demonstrating two to five years of experience. Candidates should describe how they moved from junior responsibilities to independent ownership of projects, growth in technical or domain competence, instances of mentoring junior colleagues, and examples of measurable impact. Expect questions about technologies managed, team sizes, scope of projects, and demonstrations of increasing autonomy that justify mid level seniority.

HardTechnical

95 practiced

Design a measurable framework (OKRs/KPIs) to quantify a mid-level engineer's impact over six months. Cover delivery, reliability, collaboration/communication and mentorship. For each KPI specify data sources, acceptable targets, and how you'd avoid gaming the metrics.

Sample Answer

Objective: Demonstrably improve product velocity, stability, and team health over 6 months. Measure across Delivery, Reliability, Collaboration/Communication, Mentorship with KPIs, data sources, targets and anti‑gaming controls.

1) Delivery (Outcome-focused)- KPI: Feature lead time (spec → prod) — median days per ticket - Data: Jira transitions + Git deploy timestamps - Target: Reduce median from baseline by 25% (or ≤10 days if baseline unknown) - Anti‑gaming: Exclude trivial tickets (<1pt); require linked PR + release note; periodic PM sampling to verify scope.- KPI: Percent of planned sprint scope completed (committed vs done) - Data: Sprint reports in Jira - Target: ≥85% of committed story points each sprint - Anti‑gaming: Normalize by ticket churn; require product-owner acceptance.

2) Reliability- KPI: Regression/production bug rate attributable to engineer (bugs per 1k LOC or per deploy) - Data: Issue tracker labels, root-cause tagging, blame via PR history - Target: ≤0.5 P1/P2 bugs per month; downward trend across 6 months - Anti‑gaming: Require RCA ownership for each bug; peer verification of attribution.- KPI: Mean time to restore (MTTR) for incidents where engineer is on-call/owner - Data: Incident logs, PagerDuty, runbook timestamps - Target: MTTR improvement of 30% vs baseline - Anti‑gaming: Cross-check incident notes; penalize suppressed alerts or ignored diagnostics.

3) Collaboration / Communication- KPI: Code review responsiveness and quality - Data: GitHub/GitLab metrics: time to first review, review comment depth (qualitative sampling) - Target: First review < 8 hours on workdays; average review score ≥4/5 in peer survey - Anti‑gaming: Random audit of reviews for substance; weight quality > speed.- KPI: Cross-team tickets closed (dependencies resolved) & stakeholder satisfaction - Data: JIRA linked tickets, 360° stakeholder surveys every 2 months - Target: Close ≥4 cross-team tickets; stakeholder satisfaction ≥4/5 - Anti‑gaming: Require stakeholders to confirm resolution; survey anonymity to reduce bias.

4) Mentorship & Growth- KPI: Mentees’ progress (skill rubric) and knowledge-sharing - Data: 1:1 notes, competency rubric scores pre/post, attendance of brown‑bags - Target: At least 1 active mentee with two rubric competency gains; lead ≥2 knowledge sessions - Anti‑gaming: Use standardized rubric; manager + peer verification; session feedback forms.- KPI: Contribution to team onboarding docs/tests - Data: Docs repo commits, test coverage deltas - Target: Create/update ≥3 onboarding docs; increase relevant module test coverage by ≥5% - Anti‑gaming: Review by engineering manager for usefulness; link to new hires’ ramp time improvements.

Measurement rules (general)- Combine quantitative metrics with quarterly qualitative calibration (manager + peers + PM) to prevent metric fixation.- Use moving baselines per engineer role and code ownership to ensure fairness.- Cap per-KPI weight; use a composite score (e.g., 40% Delivery, 25% Reliability, 20% Collaboration, 15% Mentorship) and require no single area to be failing.- Review and iterate KPIs every 3 months with engineer input.

HardSystem Design

85 practiced

You're tasked to lead a phased migration of a 5-year-old monolith to microservices for a core business capability used by 1M monthly users. Provide a migration plan outlining phases, data migration strategy, API compatibility, CI/CD changes, monitoring, and rollback strategies. Also list major risks and mitigations.

Sample Answer

Requirements & constraints:- Preserve 24/7 availability for 1M monthly users, <500ms p95 latency for core flows, phased delivery over 6–12 months, incremental rollback capability, minimal DB downtime, support analytics and GDPR.

High-level plan (phased):1. Discovery & design (2–4 weeks) - Map domain boundaries, data ownership, critical flows and SLAs. Define service boundaries by business capability. Establish contracts and non-functional requirements.2. Strangler-first phase (8–12 weeks per slice) - Pick a low-risk but representative capability slice (read-heavy) and extract as first microservice behind facade.3. Incremental extraction (iterative, 3–6 months) - Extract business-critical slices prioritized by coupling, risk, and benefit.4. Harden & optimize (ongoing) - Centralize cross-cutting concerns (auth, config, observability), performance tuning, and team onboarding.5. Decommission & cleanup - Remove unused monolith code and DB tables after stability windows.

Data migration strategy:- Preserve primary source until fully cutover. Prefer "dual-write + read-through cache" pattern: - Phase A: Monolith remains primary. New service reads via the monolith façade or via a shared read replica. - Phase B: Implement dual-writes (monolith writes + service writes) with idempotency and versioned events. - Phase C: Backfill historical data via batched, validated ETL; use change-data-capture (CDC) (Debezium/Kafka) to stream updates to services. - Final cutover: Flip read ownership after shadow testing and consistency checks. Keep CDC for reconciliation.

API compatibility:- Introduce an API gateway/facade that routes by path/version. Maintain backward-compatible API versions.- Use consumer-driven contract tests (Pact) enforced in CI to prevent breaking changes.- Provide feature flags and version negotiation headers. Deprecate old endpoints with telemetry.

CI/CD changes:- Move to per-service pipelines: build, unit/integration tests, contract tests, security scans, automated canary deploys.- Add automated migration tests (schema migration in staging), blue/green or canary deployment with automated rollbacks on error budgets.- Use infra-as-code for service infra (k8s/ecs), and a centralized pipeline orchestrator.

Monitoring & observability:- Centralized metrics (Prometheus), tracing (OpenTelemetry/Jaeger), structured logs (ELK/Datadog), and synthetic user flows.- Define SLOs and automated alerts for latency, error rate, data drift, and reconciliation divergences.- Implement dashboards for API gateway routing, dual-write mismatch rates, and CDC lag.

Rollback strategies:- Canary + automatic rollback on health/slo breaches.- For data: use write-intent logs and idempotent writes; on failure, stop routing to new service and continue using monolith; use CDC to reconcile.- Maintain feature flags to toggle consumers to old endpoints.

Major risks & mitigations:- Data inconsistency: mitigate with CDC + reconciliation jobs, idempotent writes, and strong monitoring.- Performance regressions: mitigate with canaries, load testing, capacity planning.- Breaking APIs for clients: mitigate with strict contract testing, versioning, gateway, and gradual deprecation.- Operational complexity: mitigate by centralizing observability, runbooks, and training.- Extended dual-write window causing drift: limit time, prioritize deterministic backfill, and alert on mismatch thresholds.- Team velocity slow-down: mitigate by cross-functional squads, clear slicing, and pairing with original monolith owners.

Why this works:- Strangler pattern minimizes user impact; CDC + dual-write ensures data safety; API gateway and contract tests protect consumers; CI/CD & observability enable fast safe iteration and rollback.

EasyBehavioral

75 practiced

Describe a time you mentored a junior engineer. Explain how you identified knowledge gaps, the specific interventions (pair programming, code reviews, learning plan), how you tracked progress, and what measurable improvement resulted.

MediumTechnical

81 practiced

You must decide whether to integrate an open-source library or build an in-house solution for a core feature. Describe the evaluation criteria (security, license, performance, maintenance), experiments or benchmarks you'd run, and how you'd present your recommendation to stakeholders.

MediumTechnical

100 practiced

You're preparing for a promotion to mid-level engineer. List the artifacts you would collect (PRs, docs, metrics, stakeholder feedback), how you'd structure a promotion case or portfolio, and how you'd discuss this with your manager and peers.

Sample Answer

Artifacts to collect- PRs: 6–10 representative PRs showing impact, complexity, and ownership (feature end-to-end, a critical bugfix, a refactor). Include links, short summary, review comments you addressed.- Design docs: architecture proposals you authored or led, RFCs, decisions with trade-offs and diagrams.- Metrics & outcomes: before/after KPIs (latency, error rates, uptime, performance, cycle time, user adoption). Attach dashboards or snapshots.- Tests & CI: evidence of test coverage, e2e/automation you added.- Mentorship & reviews: list of mentees, recurring review feedback you gave, examples where your review prevented regressions.- Stakeholder feedback: short quotes or emails from PMs, designers, ops; 360 feedback snippets.- Timeline & goals: roadmap ownership, sprint responsibilities, on-call rotations, incident postmortems you led.

Structure of the promotion case/portfolio1. Executive summary (1 paragraph): role you aim for, top 3 examples of impact.2. Competency mapping: map 6–8 artifacts to promotion rubric (ownership, craft, communication, influence).3. Deep dives (3 examples): each with context, your actions, technical details, measurable results, learnings.4. Supporting artifacts: links, screenshots, feedback, metrics.5. Development plan: gaps you’ll close and timeline post-promotion.

How to discuss with manager and peers- Prep a 30–45min meeting with your manager: share the executive summary and ask for honest calibration against the rubric; request concrete examples you should add.- Use manager as partner: ask for advocate/feedback, agree on timeline and measurable milestones.- Peer review: share draft with 2–3 trusted peers for critique on clarity and evidence; integrate their comments and ask them for short feedback snippets you can include.- Follow-up: convert feedback into an action plan, update artifacts, and schedule a checkpoint 4–6 weeks before promotion cycle.

Example phrasing to manager: “I’ve compiled a promotion portfolio mapping my work to the mid-level rubric. Could we review it together and identify any gaps I should close before the next cycle?”

Unlock Full Question Bank

Get access to hundreds of Mid Level Career Progression interview questions and detailed answers.

Join thousands of developers preparing for their dream job.