Skip to the notes
JSGroundwork
JSGroundwork handwritten · web dev
✎Playground→⌘Problems↻Review🔥Progress

Chapters

20 chapters
⌕
Beginner15›
00Scouting reportR1Screening callR2Machine codingR3JavaScript & TSR3·TSTypeScriptR4React & Next.jsR5Node & NestJSR6Databases & RedisR7DSA roundR8System designR9AWS, Docker, CI/CDR10Resume grillingR11BehaviouralR12HR & the number✓The week before
Advanced5›
50LWhat changes at ₹50L50LHard DSA50LDistributed systems50LRuntime internals50LStaff behavioural
/ search[ ] chaptert top

Ready to read

JSJavaScript⑂Git◎Interview prepΣDSA in JSSDSystem Design
More topics15›
</>HTML{ }CSS⚛ReactNNext.jsNeNest.jsTSTypeScriptNoNode.js🐳DockerDBSQL & Databases✓Testing🔒Web Security☁Cloud & DevOps◈GraphQL◆Redis☸Kubernetes
100%
R11

Behavioural & hiring manager

Length45 min
WhoEngineering manager or CTO
DecidesYour level, and often your number
Fail modeGeneric answers with no specific story
serviceproductsaasagency

Prepare six real stories and you can answer any question in this round, because the twenty questions map onto the same handful of events. Situation, task, action, result — and spend most of the time on the action, because that is the only part that is about you.

1 · A production failure you owned

What broke, how you found out, the first ten minutes, and the structural change that made recurrence impossible.

2 · A disagreement you lost

You argued a technical position, did not win, committed fully anyway, and it worked out. More valuable than one you won.

3 · A difficult client or stakeholder

Scope change, an impossible deadline, or a demand you pushed back on. You have three agencies of material.

4 · Shipping under real time pressure

What you deliberately cut, and how you made sure the debt was recorded rather than quietly forgotten.

5 · Someone you made better

A specific junior, a specific weakness, what you did, and what they can do now that they could not before.

6 · A decision you reversed

You committed, evidence came in against it, and you changed course. Shows you update on data rather than on ego.

11.1
Tell me about a time you disagreed with a technical decision.
What they are really testingWhether hiring you means hiring an argument.

The strongest version of this story ends in one of two places: "and I was wrong", or "and I lost, and I committed fully anyway, and here is how I made it work."

Managers are screening for disagree-and-commit. A candidate who wins every story they tell is either lucky, or is telling you they do not let things go.

The answer that loses the room

The story where you were right, they did not listen, and it later broke — told with satisfaction. Even when true, the tone is what gets scored, and it reads as "I will say I told you so."

They will push with
  • What would you do if the same thing happened here?
  • How did the other person feel about it afterwards?
11.2
Your app is down in production and you are the only engineer available. What do you do?
What they are really testingWhether your instinct is to restore or to investigate. There is a right answer.

In this order, and the order is the answer:

  1. Confirm the blast radius. Everything, or one endpoint? All users, or one tenant?
  2. Communicate immediately, before you have a diagnosis, with an expectation for the next update. Silence is what turns an outage into a relationship problem.
  3. Restore service. Roll back to the last known good release. Do not debug production while it is down.
  4. Verify recovery against a real user path, not just a health check returning 200.
  5. Then investigate, on the artifact and the logs, not on the live system.
  6. Blameless write-up with one concrete prevention action that has an owner and a date.
They will push with
  • What if rolling back is not possible because of a migration?
  • Who do you tell first?
  • What goes in the write-up?
11.3
Why do you want to work here?
What they are really testingWhether you researched. On a walk-in day this is where most candidates are visibly caught out.

Ten minutes on their website and LinkedIn before you walk in — for every company, in the queue if necessary. Then name their product, name something specific about the problem it solves, and connect it to something you have actually built.

"You are solving X, and the closest thing I have built is Y, which is why the problem is interesting to me" beats any amount of enthusiasm. Enthusiasm without specificity reads as the same answer you gave the company down the road.

The answer that loses the room

"I've heard great things about the culture" and "I want to work with cutting-edge technology." Both are content-free, both are said by everyone, and both signal you did not look them up.

They will push with
  • What do you think our biggest technical challenge is?
  • Who do you think our competitors are?
11.4
Where do you see yourself in three years?
What they are really testingWhether you will still be there. They are pricing the cost of replacing you.

For your profile the answer that lands is depth, not title: owning a system end to end, being the person the team asks about the architecture, growing into technical leadership through influence rather than headcount.

If you genuinely want people management, say so — but frame it as an interest to grow into, not a condition. And do not say "running my own company", however true, in a round designed to test retention.

They will push with
  • What would make you leave after a year?
  • Do you want to manage people?
11.5
You have worked remotely for three years. How will you work in an office team?
What they are really testingA real question for you specifically, and the interviewer may not ask it directly — they will just wonder.

Get ahead of it. Frame remote as having made you better at the things offices are bad at — written communication, asynchronous decision records, making your work visible without being seen — and then say plainly that you moved cities to be in a room with people, which is a stronger signal than any answer.

They will push with
  • How do you handle a disagreement over text?
  • What did you find hardest about remote work?
11.6
The rest of the round
What they are really testingSame six stories, twenty different doors into them.
  • Tell me about a project that failed.
  • How do you handle competing priorities from two stakeholders?
  • Describe a time you had to learn something quickly.
  • How do you give critical feedback on a colleague's code?
  • How do you receive it? Tell me about feedback that stung.
  • What do you do when you are blocked?
  • Describe your ideal team and your ideal manager.
  • How do you keep quality up when the deadline will not move?
  • Tell me about a time you said no.
  • What motivates you, and what makes you disengage?
  • Tell me about a time you had to work with someone difficult.
  • How do you decide when something is good enough to ship?
  • What is the hardest bug you have ever debugged? (Have a real one, with the diagnostic path — this doubles as a technical question.)
  • What do you do outside work? (You have a public learning platform with 85 chapters written. Lead with it — it is genuinely differentiating and it evidences everything else you have claimed about standards and mentoring.)
  • What questions do you have for me? (Never "none." See below.)
11.7
What you ask them — and the one question almost nobody asks
What they are really testingThis is scored. Two or three good questions, tailored to who is in front of you.

To the engineer who interviewed you

  • What does the path from merged pull request to production look like, and how long is it?
  • What is the test and code review culture actually like — not aspirationally?
  • What is the part of the codebase everyone is slightly afraid of?
  • How much of your week is feature work versus maintenance and incidents?

To the hiring manager

  • What would someone need to have done in the first six months for you to consider this hire a clear success?
  • Why is this role open — growth, or a replacement?
  • How does the team decide what gets built, and how much say does engineering have?
  • What is the biggest technical risk facing the team in the next year?

To HR

  • What is the fixed-to-variable split, and what percentage of variable was actually paid out last year?
  • How does the appraisal cycle work, and what was the average increment last cycle?
  • Is there a formal engineering level structure, and where would this role sit?
2026 note

The one worth asking every single time: "Is there anything about my background that gives you hesitation, that I could address now?" It is uncomfortable and it works. Either you get to answer the objection while you are still in the room, or they say no and you have closed the loop cleanly. Almost nobody asks it, and interviewers remember the people who do.

←previousResume grilling↑ CovernextHR & the number→