A junior interview without a real project is a quiz. With one, it becomes a conversation about work, and the questions are the same ones a senior gets asked about theirs. That is good news, if you have prepared for them. Here are the eight we would ask.
1. Walk me through the system you worked on.
What it tests: whether you understand the shape of the thing, not just your corner of it. How to answer: start from the user and the problem, then the main modules, then where your part sat and what it talked to. If you read a solution architecture before you wrote code, this is where it pays off. Draw it if there is a whiteboard.
2. What was your part, exactly?
What it tests: honesty and precision. How to answer:name the module, the tickets, the sprints. Say what you did not do. “I built the booking module; a teammate built the admin view; the mentor wrote the architecture” is a stronger answer than a vague claim on the whole system, because it is checkable.
3. Tell me about a review comment that changed your code.
What it tests: whether you have been reviewed by someone senior, and what you did about it. How to answer: pick one specific comment. The query in the loop. The untyped result. Say what the reviewer wrote, why they were right, what you changed, and what you now do differently by default. This is the question most juniors cannot answer at all; you can answer it with a line number.
4. What broke, and what did you do?
What it tests: production sense. How to answer:something did break, or nearly did; say what, how you found out, what you did in the first ten minutes, and what you changed so it would not happen again. If the honest answer is “nothing broke in production, but the review caught this before it could”, that is a fine answer too.
5. How did you work with the client?
What it tests: whether you can ask a question properly. How to answer: describe one product decision that was not yours to make, how you asked the point of contact, and how you kept it to one message instead of five. Mention the cadence: weekly check-ins, questions answered within a business day, blockers flagged early rather than after the deadline slipped.
6. What would you change if you built it again?
What it tests: reflection. How to answer:one architectural thing and one personal thing. “I would model the status as an enum from the start; and I would open smaller pull requests, because the reviews on the big ones took two rounds.” Do not say “nothing”.
7. Can I see it?
What it tests: whether the project exists. How to answer: yes. Your public Anvil Stamp page lists the project, your role and the date it completed. If the client granted the brand reference, name them. If the code is private, say so plainly and offer to walk through the architecture instead. Never show client code you were not cleared to show; the interviewer will respect the boundary more than the code.
8. Who can I talk to about your work?
What it tests: whether a senior will vouch for you. How to answer: your project mentor, with their permission arranged in advance. A working senior engineer who reviewed your pull requests for weeks is the reference most junior candidates do not have.
Preparing in an evening
- Reread your own pull requests and the review comments on them. Pick your three best stories: one review, one bug, one client question.
- Draw the system from memory, then check it against the architecture. Fix what you got wrong.
- Confirm the Anvil Stamp link resolves and the reference is arranged.
If you do not have a project to answer these from yet, that is the first thing to fix, and it is what the apprenticeship is for. The questions will still be waiting; the difference is whether you have answers.