Junior · Backend

Interview questions for a junior backend engineer.

Junior hires should be evaluated on fundamentals and coachability, not esoterica. These ten do that without algorithm-bowl theatrics.

10 questions · rubric-backed · Built for small-team hiring panels
The rubric these map to
45%
Technical depth
Workload-first reasoning · trade-offs articulated · senior-level nuance unprompted.
15%
Experience relevance
Resume-anchored probes. Specifics + numbers beat adjectives.
15%
Attitude & ownership
Incident response, escalation judgment, what they'd institutionalize afterward.
10%
Communication clarity
Technical trade-offs explained without jargon creep.
15%
Culture fit
Behavior-based, scored against your explicit values.

The questions.

  1. 01
    technical baseline · postgres

    You have a Postgres table with 500M rows of loan applications. A query filtering by applicant_id (indexed) and status (not indexed) takes 3 seconds. Walk me through how you'd diagnose and fix this.

    Strong answer
    Asks about workload before jumping to solutions · proposes EXPLAIN ANALYZE · mentions partial or composite indexes, not just 'add an index' · seniors reference statistics, vacuum, or plan cache unprompted.
    Weak answer
    Immediately says 'add an index on status.' Doesn't ask about cardinality. Doesn't mention the query planner.
  2. 02
    situational medium · teammate-conflict

    A teammate ships a change you think is wrong after the fact. Already in production. What do you say, what do you do?

    Strong answer
    Separates the product concern from the relationship concern. 1:1 first. Focuses on systemic change (PR review, tests) — not on blame.
    Weak answer
    Avoids the conversation or jumps to escalation. Assigns blame. No systemic improvement suggested.
  3. 03
    communication baseline · explaining

    Explain recursion to a non-programmer.

    Strong answer
    Uses a concrete analogy (matryoshka dolls, mirrors, etc). Avoids jargon. Checks for understanding.
    Weak answer
    Jumps into function-calls-itself definition. Condescending or confusing.
  4. 04
    technical hard · observability

    What does a useful logging + metrics + tracing stack look like for a service with 100M requests/day?

    Strong answer
    Distinguishes logs/metrics/traces by use case. Knows sampling strategies. Structured logs. Cardinality discipline. Mentions specific tools without being dogmatic about them.
    Weak answer
    Conflates logs and metrics. No sampling strategy. Suggests logging every request body (cardinality disaster).
  5. 05
    experience baseline · resume-probe

    You mentioned a college / internship project. What was the hardest part?

    Strong answer
    Specific hard thing. Specific resolution. What they learned — new skill or mental model, not just 'teamwork.'
    Weak answer
    Generic answers about 'time management' or 'learning new tech.'
  6. 06
    situational baseline · stuck

    You've been stuck on a bug for 3 hours. What do you do?

    Strong answer
    After reasonable time (not 3 hours), asks for help. Articulates what they've tried. Doesn't spiral.
    Weak answer
    Keeps grinding alone. Or gives up without articulating what they've tried.
  7. 07
    technical medium · api-design

    You're designing an API endpoint that returns a user's feed. Pagination strategy? Why?

    Strong answer
    Discusses cursor vs offset-based pagination · knows when each is appropriate · mentions stability under inserts · sets sensible default + max page size · considers ETag/If-None-Match for caching.
    Weak answer
    Picks offset pagination by default without considering stability. No max page size. No caching thought.
  8. 08
    technical baseline · git

    You committed to the wrong branch. How do you fix it?

    Strong answer
    git stash, switch branch, git stash pop — or cherry-pick. Doesn't use force push on shared branches.
    Weak answer
    Panics. Or force-pushes on main.
  9. 09
    situational medium · incident-response

    It's Saturday 11pm. A loan-disbursal job is failing silently. The team that built it no longer exists. Walk me through what you do in the next hour and next 48 hours.

    Strong answer
    First hour: triage scope + comms to right people + restore service before root-causing. Next 48h: postmortem, takes ownership of the service, suggests durable change to prevent silent failures.
    Weak answer
    Stops at 'check the logs.' No comms plan. Next 48h is 'fix the bug.'
  10. 10
    technical hard · scaling

    Walk me through how you'd scale a write-heavy service from 100 to 10,000 writes/sec. What breaks first?

    Strong answer
    Starts with profiling current bottleneck, not with 'add Kafka.' Acknowledges write-amplification, index bloat, replication lag. Discusses shard keys + hot-partition mitigation.
    Weak answer
    Jumps to 'we'd add a queue and scale horizontally' without identifying where the current bottleneck is.
Why stop at ten?

Lucida runs round one for you, and books the shortlist on your calendar.

Adaptive interviews tuned to the role, rubric-backed scoring, and a founder-ready briefing for every candidate who clears the bar. You do the human call.

Try it on your next role → See how Lucida works
Related interview question sets