Interview Preparation
Before you start
You need: a working project (Article 09). Preparation without something built is memorisation, and it does not survive follow-up questions.
Time: about 45 minutes to read. Then four weeks of preparation, running alongside applications — not before them.
Learning objective
Know what each round assesses, prepare for it deliberately, and be able to walk through your own project convincingly.
Topics
- Start applying before you feel ready
- The rounds, and what each assesses
- The four-week preparation plan
- The project walkthrough that decides it
- How to say "I don't know"
- What they are really assessing
- After the interview
Start applying before you feel ready
You will not feel ready. Apply anyway.
The candidate who applies in month five with a good project and rough interview skills gets more offers than the one who prepares until month eight and applies polished. Two reasons: interviews teach you interviewing in a way practice cannot, and roles are filled while you prepare.
Your first three interviews will go badly. Treat them as calibration. You will discover which questions you cannot answer, and that is worth more than another week of revision.
Month 5 Apply to roles you are slightly under-qualified for. Learn.
Month 6 Apply properly, with the walkthrough rehearsed.
Apply widely. Fresher hiring has a low response rate — that is normal and not about you. Fifty applications producing five conversations is an ordinary ratio.
The rounds, and what each assesses
| Round | Length | What they actually assess |
|---|---|---|
| Screening | 15–30 min | Can you communicate? Is the resume true? |
| Technical | 45–60 min | Can you reason, or only recall? |
| Machine coding | 60–120 min | Can you build something small, cleanly? |
| Managerial / HR | 30 min | Will you be manageable and will you stay? |
The technical round is not a quiz. They are testing whether you can think about a problem you have not seen. Someone who reasons out loud and reaches a decent answer beats someone who recites a definition and cannot go further.
Not every company runs all four. Service companies often run screening plus technical plus HR. Product companies more often include machine coding. Startups sometimes do one long conversation.
The four-week preparation plan
Alongside applications, not instead of them.
Week 1 — Your own project
The highest-value week, because most fresher questions come from your project.
- Reread your own code. All of it
- For every significant decision, write one sentence on why
- Rehearse the five-minute walkthrough out loud, timed
- Trace one request through every layer, out loud, without notes
- List every hard case you handled — absent students, duplicate roll numbers, cross-school isolation
Out loud is not optional. Explaining in your head is far easier than explaining in a room, and the gap surprises people.
Week 2 — Fundamentals
Work through Article 11 properly. Say each answer aloud before reading the model answer.
Focus on the topics that produce follow-up questions: decimal versus double, absent versus zero, First versus FirstOrDefault, joins that drop or multiply rows, why SchoolId comes from the token.
Week 3 — Mock rounds and coding
- Run the rounds in Article 12
- Practise writing code on paper or a shared doc, with no IDE
- Practise a small machine-coding task in 60 minutes
Practise without autocomplete. Whiteboard and shared-document rounds remove the tooling you have relied on for six months, and that is a shock the first time.
Week 4 — Presentation
- Article 13 — resume, GitHub, LinkedIn
- Rehearse "tell me about yourself" — 90 seconds, not five minutes
- Prepare your questions for them
- Test your setup if the interview is remote: camera, microphone, screen sharing, a quiet room
The project walkthrough that decides it
This is the single highest-value thing you can prepare. In most fresher interviews it takes up more time than anything else, and it is where the offer is decided.
Six parts, five minutes:
1. The problem
"The school office spent several minutes finding one student's record
while a parent waited on the phone, and fee receipts were handwritten."
2. The stack, and why
"React, ASP.NET Core, Dapper, SQL Server. I chose Dapper over EF Core
because the application is reporting-heavy and I wanted to see and
tune the SQL."
3. One request, end to end
"A clerk clicks Print. The browser sends a GET with the JWT. The
controller reads schoolId from the claim — never from the request —
and calls FeeService. The service calls FeeRepository, which runs a
stored procedure joining three tables, filtered by SchoolId. The
service builds a DTO with only what the clerk may see, and the
component renders it with a print stylesheet."
4. A hard decision
"Absent exam results are stored as NULL, not 0. Zero would drag every
class average down by about 12% with no error anywhere. So the absent
check comes first in every grading chain."
5. A bug you found
"Receipts showed a zero balance for one student. I traced it: the
frontend rendered what the API sent, the API's SQL was running, and
the database had two fee accounts for that student — he had repeated
a year. FirstOrDefault picked the older one. I filtered by academic
year and added a test."
6. What you would add next
"Pagination on the fee report, an audit trail on fee changes, and a
second-approval step on discounts."
Part 5 is the one interviewers remember. It shows a method — trace the boundaries, find the cause, fix it minimally, add a test — rather than luck. Prepare a real one.
Part 4 shows you made a decision rather than following a tutorial.
Part 6 shows judgement. Knowing what is missing reads as more senior than claiming nothing is.
Rehearse it aloud until it is five minutes and not fifteen. Then be ready to be interrupted at any point and go deeper — that is the actual test.
How to say "I don't know"
You will be asked something you cannot answer. How you handle it is itself assessed.
Bad: [silence]
Bad: [a confident guess that is wrong]
Bad: "We didn't cover that."
Good: "I haven't used that. From the name I'd guess it does X —
is that roughly right?"
Good: "I don't know that one. I do know the related thing —
shall I tell you what I'd do instead?"
Good: "I don't know. How would I find out? I'd check the docs and
test it in a small console app before using it."
Interviewers expect gaps in a fresher. What they are testing is whether you bluff — because a developer who bluffs in an interview will bluff in a code review, and that is expensive.
Never guess confidently. One confident wrong answer costs more than three honest "I don't know"s, because it makes everything else you said suspect.
What they are really assessing
Beneath the questions, four things:
Can you communicate? Most of the job is explaining. A candidate who explains clearly with slightly weaker technical skills often wins.
Can you reason, or only recall? Definitions are cheap now. Working through a problem out loud is the signal.
Are you honest? Gaps are fine. Hidden gaps are not.
Will you be manageable? Do you take feedback? Do you ask when stuck? A fresher who says "I was stuck for three days and didn't want to bother anyone" is a genuine worry.
None of these are about knowing more. They are about being someone a team can work with — which is why the walkthrough and the honest "I don't know" matter as much as the technical answers.
After the interview
Write down every question you could not answer. Within an hour, while you remember. That list is your revision plan and it is worth more than any guide.
Learn the answers before the next one. The same questions recur across companies.
Send a short thank-you if you have the interviewer's email. Two sentences.
If you are rejected, ask for feedback. Most will not reply; some will, and that reply is unusually valuable.
Rejection is normal and mostly not about you. Roles get filled internally, budgets get pulled, someone with two years' experience applied. Keep applying.
Common mistakes
- Preparing for months instead of applying and learning
- Rehearsing in your head rather than out loud
- A walkthrough that runs fifteen minutes
- Bluffing instead of admitting a gap
- Not being able to explain your own code
- Answering only the question asked, with nothing behind it
- No questions for them at the end
- Not writing down what you could not answer
- Applying to five roles and concluding the market is closed
Practice
- Reread your entire project. Write one sentence on each significant decision.
- Write your six-part walkthrough. Time it aloud. Cut it to five minutes.
- Trace one request through every layer, out loud, without notes.
- Prepare a real bug story — what broke, how you traced it, the fix, the test.
- Rehearse three ways of saying "I don't know" until they are comfortable.
- Write "tell me about yourself" in 90 seconds. Rehearse it.
- Prepare three questions for them. Not about salary.
- Apply to five roles this week, ready or not.
- After each interview, write down every question you could not answer.
- Learn those answers before the next one.
You can now
- Say what each round assesses
- Give a five-minute project walkthrough without notes
- Trace one request through every layer out loud
- Tell a real bug story with a method behind it
- Say "I don't know" in a way that helps you
- Name the four things actually being assessed
- Turn a bad interview into a revision plan
Review questions
- Why apply before you feel ready?
- Which part of the walkthrough do interviewers remember, and why?
- Why does one confident wrong answer cost more than three honest gaps?
- What is the most valuable thing to do in the hour after an interview?
Next: The question bank