Junior Backend Engineer
Structured interview questions for Junior Backend Engineer, with what a strong answer surfaces for each one.
BehavioralBackend fundamentals Walk me through a backend project or feature you built end to end (side project, bootcamp capstone, internship). What decisions did you make and what was the hardest part?
What a strong answer surfacesEvidence of shipping something complete, however small: a data model, an endpoint, a deployment. Honest reflection on what was hard and what they'd do differently. Bonus: they can explain a trade-off they made (why a table instead of a file, why REST). A vague tutorial-follower answer with no ownership is a weak signal.
BehavioralAutonomy and resourcefulness Tell me about a time you were stuck on a technical problem you didn't know how to solve. What did you do?
What a strong answer surfacesA structured way of getting unstuck: reading docs and error messages, searching, minimal reproduction, asking for help after a genuine attempt (with a summary of what they tried). Bonus: they mention learning something reusable from it. Someone who just waited to be told the answer shows weak resourcefulness.
BehavioralCoachability Describe a time you got critical feedback on your code or your work. How did you react?
What a strong answer surfacesOpenness and the ability to separate feedback from ego. Bonus: a concrete case where feedback changed how they work. For a junior, coachability is the single most important trait; defensiveness here is a serious flag at an SMB with a small team.
SituationalPragmatism and prioritization You're asked to add a new field to an API endpoint and store it in the database. You've never touched this codebase. How do you approach it?
What a strong answer surfacesA sensible path: read the existing similar code first, follow the conventions already there, make a small change, test it locally, ask a targeted question if blocked. Bonus: they mention checking whether a migration is needed. Someone who wants to rewrite things their way on day one shows poor judgement.
SituationalCoachability Your code passes locally but a reviewer points out it breaks when the input is empty. How do you handle it?
What a strong answer surfacesGratitude for the catch, a quick fix, and ideally adding a test so it can't regress. Bonus: they reflect on checking edge cases (empty, null, very large) proactively next time. A defensive but it worked on my machine answer is a coachability flag.
SituationalAutonomy and resourcefulness You realise halfway through a task that you don't understand part of the requirement. It's mid-afternoon. What do you do?
What a strong answer surfacesAsking early rather than guessing and burning a day: a concise, specific question to the right person, with context on what they've understood so far. Bonus: they try to answer it themselves first (read the ticket, the code). Silently building the wrong thing is the failure mode to screen out.
TechnicalBackend fundamentals In plain terms, what happens when a client makes an HTTP request to your API? Walk me from the request to the response.
What a strong answer surfacesA clear mental model at the right level: routing, handler, maybe a database query, a response with a status code. Bonus: they mention status codes, JSON, or validation. You're checking for a coherent picture, not senior depth. Total confusion here is a concern for an entry backend role.
TechnicalDatabase fundamentals What is a database index, and why would you add one? What's a downside?
What a strong answer surfacesThe basic idea (faster reads by avoiding a full scan) and at least one downside (slower writes, storage). Bonus: they connect it to a query they'd want to speed up. Not knowing what an index is at all is a gap for a backend role, but a partial answer with sound intuition is fine at junior level.
TechnicalDatabase and security hygiene Why should you never build a SQL query by pasting user input directly into the string? What do you do instead?
What a strong answer surfacesAwareness of SQL injection and the fix (parameterized queries / prepared statements). You don't need a security specialist, but a junior backend hire should know not to concatenate user input into SQL. Bonus: they mention validating input as a second layer.
ValuesCoachability How do you like to learn on the job — pairing, docs, reading code, asking questions? How do you want to be supported in your first months?
What a strong answer surfacesSelf-awareness about how they learn and a realistic appetite for mentoring and pairing. Bonus: they ask about your onboarding, review culture or mentoring. Someone who expects to be fully independent immediately, or who wants zero guidance, is a poor fit for a junior role at an SMB.
ValuesCross-functional teamwork How do you work with teammates when you disagree, or when you need help but everyone looks busy?
What a strong answer surfacesA collaborative posture: asking respectfully, timeboxing solo attempts, being comfortable saying I don't know. Bonus: an example of helping a peer in return. At an SMB the junior's willingness to ask and to collaborate directly affects how fast they become productive.
ValuesMentoring and knowledge sharing Where do you want to be technically in two years, and what do you want to get better at first?
What a strong answer surfacesGenuine curiosity and a growth mindset with some direction (a stack, a domain, an area like databases or APIs). Bonus: it's realistic and connects to the role. You're checking that the role and their trajectory point the same way, which drives retention for junior hires.
Evaluation playbook
For a junior Backend Engineer the evaluation shifts away from track record and toward fundamentals, learning speed and coachability. The bounded coding task (stage 3) is the most predictive step; a full system-design exercise matters far less than at mid or senior level.
Stage 1: CV and portfolio review
With little or no professional experience, weight the portfolio over the CV: a visible GitHub, a finished side project deployed somewhere, a bootcamp capstone, a relevant internship or working-student stint. Look for signal that the candidate has shipped something end to end, however small, rather than only followed tutorials. The degree matters less than evidence of building.
Stage 2: Phone screen (30 min)
Three questions: (1) Walk me through a project you built and are proud of; what was hard? (2) How do you get unstuck when you hit something you don't know? (3) Why backend, and why us? Outcome: go/no-go. Assess motivation and communication, not deep technical knowledge.
Stage 3: Bounded coding task (60 min, pairing)
Pair on a small, realistic task (add a simple endpoint, fix a bug, model a small table). Assess whether they can read existing code, reason out loud, use documentation, and iterate on feedback. Coachability shows here: do they incorporate a hint and improve, or get defensive? Avoid algorithmic gotchas; favour everyday tasks.
Stage 4: Fundamentals conversation (30 to 45 min)
A discussion (not an exam) on backend basics: what an HTTP request is, what a database index does, request/response vs. async, why you validate input. You are checking for a clear mental model and honesty about the edges of their knowledge, not senior-level depth. A confident I don't know that yet, but here's how I'd find out is a good answer.
Stage 5: References or a check-in
For recent graduates, a reference from a bootcamp instructor, internship manager or working-student supervisor. Ask about learning speed, reliability and how they take feedback — the three traits that most predict a junior's first year.
How to recognize a great hire
| Trait | Below bar | On bar | Above bar |
|---|---|---|---|
| Backend fundamentals | Confused about the basics (HTTP, requests/responses, what a database does). Copies code without a mental model. Would need heavy hand-holding on every task for months. | Has a working mental model of the fundamentals from a bootcamp, degree or side projects. Can build a simple endpoint or query with guidance and grows quickly with review. The expected level for a strong junior. | Unusually solid fundamentals for a junior: understands indexing, status codes, validation and async at a conceptual level, and applies them without prompting. Effectively a fast-track profile toward mid-level. |
| Learning speed and coachability | Slow to absorb feedback or repeats the same mistakes. Defensive in review. Waits to be told the answer rather than trying first. | Takes feedback well and applies it. Learns a new tool or convention within a sprint or two with support. Asks for help after a genuine attempt. | Learns remarkably fast: incorporates a hint and generalises it, picks up conventions on the first pass, and starts helping onboard the next new joiner. The trait that most predicts a junior's first year. |
| Autonomy and resourcefulness | Blocks silently for hours, or asks at the first obstacle with no prior attempt. No method for reading docs or error messages. | Tries the obvious paths (docs, error messages, existing code) before asking, and asks well-scoped questions with context. Stays functional on familiar tasks. | Resourceful beyond their level: reads library code, reproduces a bug minimally, and unblocks themselves on unfamiliar topics, while still knowing when to ask early. |
| Communication and teamwork | Struggles to explain what they built or where they're stuck. Silent in stand-ups. Uncomfortable asking for help or admitting gaps. | Explains their work and their blockers clearly enough for the team to help. Comfortable saying I don't know. Collaborates and asks respectfully. | Communicates unusually well for a junior: writes clear PR descriptions, gives useful context, and already helps peers. A strong culture add on a small team. |
30 / 60 / 90 day success plan
By day 30
- Local development environment set up with support, access to the main backend services, and a first small PR merged to production with review
- Completed onboarding on the team's conventions, review process and where to ask for help
- Guided reading of one business-critical service with the mentor, plus a first documented 1:1 on expectations
By day 60
- Delivers small, well-scoped tickets (bug fixes, small endpoints) mostly independently, asking targeted questions when blocked
- Writes tests for their own changes and starts giving small, constructive review comments on peers' PRs
- Comfortable navigating the codebase and the main data models without step-by-step guidance
By day 90
- Owns a small feature end to end (with review at the design step), from ticket to deployment
- Visibly faster ramp on new tasks; needs help mainly on genuinely new concepts rather than day-to-day work
- Formal check-in with the mentor and tech lead: ramp on track, a clear growth plan for the next quarter