Published / updated29 Aug 2026

Mock Interview Rounds

Before you start

You need: Article 11 worked through aloud, and a project you can demonstrate.

Best done with another person. A friend on the same programme works — take turns. Alone, record yourself; it is less useful but far better than nothing.

Time: about three hours to run all four rounds.

How to run these

Do not read ahead. Have your partner read the round and ask the questions; you answer cold. Reading the questions first turns it into revision, which you have already done.

Time each round strictly. Running long is one of the things being measured.

Record it if you can. Watching yourself is uncomfortable and it is the fastest way to notice that you say "basically" forty times or never finish a sentence.

After each round, write down every question you could not answer. That list is worth more than the round itself.

Round 1 — Screening · 20 minutes

Usually HR or a recruiter, often on the phone. They are checking that you can hold a conversation and that your resume is true. Technical depth is not the point.

The questions:

1. Tell me about yourself. (90 seconds — they are timing you, informally)
2. Walk me through your project in two minutes.
3. What technologies have you worked with?
4. Are you comfortable with C# and SQL? (or Python)
5. Why do you want to work here?
6. When can you start? What are your salary expectations?
7. Do you have any questions?

What they are assessing:

Signal	What it tells them
You answer in 90 seconds, not five minutes	You can judge an audience
You describe the project clearly	You can communicate
Your claims match your resume	You are honest
You know something about the company	You are actually interested
You have questions	You are engaged

The most common failure: rambling. Ninety seconds means ninety seconds. Rehearse it with a timer.

On salary: a range is fine. "I am looking for something in the market range for a fresher — around ₹X to ₹Y. I am more interested in the work and the team at this stage." Do not say "whatever you offer"; it reads as no self-assessment.

Round 2 — Technical · 45 minutes

A developer or team lead. They are assessing whether you can reason, not whether you can recall.

Part A — Your project (20 minutes)

1. Walk me through your project.
2. Why did you choose that stack?
3. Trace one request from the browser to the database and back.
4. What was the hardest bug you hit? How did you find it?
5. What would you do differently if you started again?

Part B — Fundamentals (15 minutes)

Drawn from Article 11. The interviewer picks six:

6. Value types and reference types?
7. Why is money decimal?
8. INNER JOIN versus LEFT JOIN?
9. What is dependency injection, and why bother?
10. How do you stop SQL injection?
11. What happens if you forget await?
12. 401 versus 403?

Part C — Reasoning (10 minutes)

The part that actually decides it. There is no memorised answer.

13. "A user says the fee page is showing the wrong balance. How do you investigate?"
14. "Your API works locally and fails in production. Where do you start?"
15. "How would you add a feature letting a parent see only their own child's results?"

What they are assessing in Part C:

Good	Bad
Asks a clarifying question first	Starts guessing immediately
Narrows systematically — browser, API, SQL	Jumps to a random cause
Says what they would check and why	Names a fix with no diagnosis
Admits what they do not know	Bluffs

Model shape for question 13:

"First, can I reproduce it — is it one student or all of them? Then I would open the Network tab and look at what the API actually returned. If the API returned the wrong number, the frontend is fine and I move to the API log to see what SQL ran. Then I would run that SQL in SSMS against the same student. That tells me whether it is the query or the data. On my project this exact thing turned out to be a student with two fee accounts and no year filter in the query."

That answer works because it is a method, not a guess.

Round 3 — Machine coding · 60 minutes

More common at product companies. They are assessing whether you can build something small and clean under mild pressure.

The task:

Build a small console or API application that manages exam results for a class.

• Add a result: student name, subject, marks out of 100
• A student may be marked absent instead of having marks
• List all results for a subject
• Show the class average, and the pass count where the pass mark is 35

60 minutes. You may look things up. Talk through what you are doing.

What they are assessing:

They watch for	Because
Do you ask about the absent case?	It is the ambiguity deliberately planted
Do you handle an empty list?	Average over nothing crashes
Is the code readable?	Someone maintains it
Do you name things well?	Same reason
Do you test as you go?	Or do you write it all and hope
Do you talk while working?	Silence is hard to assess

The trap is deliberate. "A student may be marked absent" is the whole exercise. If you store absent as 0, your class average is wrong and the interviewer will ask about it. If you ask "should an absent student be excluded from the average, or count as zero?" in the first two minutes, you have already done well.

Ask clarifying questions before writing anything. It is not a stall; it is the behaviour they want to see.

If you run out of time, say what is missing and how you would finish. An honest "I have the add and list working, the average needs the absent case excluded and I have not written that yet" is far better than a silent half-finished file.

Round 4 — Managerial and HR · 30 minutes

A manager, or HR with the manager. They are assessing whether you will be manageable and whether you will stay.

1. Tell me about a time you were stuck. What did you do?
2. Tell me about feedback you received. How did you respond?
3. How do you learn something new?
4. Do you use AI tools? How?
5. What do you do when you disagree with a senior developer?
6. Where do you see yourself in three years?
7. Why should we hire you rather than someone with experience?
8. Do you have questions for us?

Model answers for the two that catch people:

Question 5 — disagreement:

"I would ask why first — usually there is context I do not have. If I still disagreed I would say so once, with my reasoning, and then go with their decision. On a review comment I had about a loop I had written, they turned out to be right about something I had not considered."

Question 7 — why you over experience:

"For a role that genuinely needs experience, you should hire experience. What I bring is that I have built something end to end recently and I can explain every decision in it, I am used to having my work reviewed, and I will ask when I am stuck rather than losing three days. I am cheaper to correct now than in a year."

On question 4, the AI one: answer it specifically. "Yes, for boilerplate and explaining unfamiliar code, and I review it — here is a thing I caught" is a much better answer than either "no" or "yes, all the time".

Scoring yourself

After all four, honestly:

	1–5
Kept "tell me about yourself" to 90 seconds
Walked through the project in five minutes without notes
Traced a request through every layer out loud
Told a real bug story with a method
Answered six fundamentals without hesitating
Asked a clarifying question before solving
Said "I don't know" cleanly at least once
Asked the absent-case question in the coding round
Handled the empty case in code
Had questions at the end

Under 35 — run them again in a week, after revising what you missed.

Over 40 — start applying, if you have not already. You are readier than you feel.

Any single score of 1 or 2 — that is your week's revision, and it is worth more than a general re-read.

Common mistakes

• Reading the questions before being asked them
• Running long and never being told
• Answering the fundamentals and skipping the reasoning practice
• Not talking during the coding round
• Missing the absent-case question in Round 3
• Preparing only technical answers, then fumbling Round 4
• Not recording, so you never see your own habits
• Running the rounds once and considering it done

Practice

1. Find a partner on the same programme. Take turns, one round each per session.
2. Run Round 1 with a timer. Cut your introduction to 90 seconds.
3. Run Round 2 cold. Have them interrupt your walkthrough and go deeper.
4. Do the Round 3 task in a real 60 minutes, talking aloud the whole time.
5. Run Round 4 and answer question 5 honestly rather than diplomatically.
6. Score yourself on the ten items.
7. Write down every question you could not answer. Revise those, not everything.
8. Run all four again a week later. Compare the scores.

You can now

• Give a 90-second introduction and a five-minute walkthrough
• Answer a reasoning question with a method rather than a guess
• Ask clarifying questions before writing code
• Handle the absent case and the empty case under time pressure
• Answer the behavioural and AI questions specifically
• Score yourself honestly and turn gaps into a revision plan

Next: Resume, GitHub and LinkedIn