HR Interviews in Tech: Common Questions & How to Answer (No Clichés)

HR interviews in tech look like the easy round - no code, no whiteboard - which is exactly why so many engineers and product people fail them. Generic answers like "I'm a perfectionist" or "I'm a team player" sound identical to the twenty candidates before you. This guide covers the behavioral questions that come up specifically in technology teams: production incidents, technical disagreements, tech debt and code review, with a full sample answer for each and what the interviewer is really testing.

If your next round is a technical one, read our guide to technical interviews in tech as well. And if you're still getting interviews in the first place, start with messages to recruiters that get answered.

What does an HR interview in tech actually test?

Team and culture fit, stability, motivation for this specific role, communication, and the practical side - notice period, salary expectations and availability. Technical depth is tested elsewhere; here they check whether you are someone people will be glad to work with.

A typical process starts with a short recruiter phone screen, continues with one or more technical rounds, and ends with an HR or "fit" interview with the hiring manager or the people team. Large companies sometimes add personality tests or an assessment day, and almost everyone checks references at the end. Each stage asks differently, but behavioral questions show up in nearly all of them.

How do you answer a behavioral question with STAR?

Tell one real story in four parts: Situation, your Task, the Action you took, and the Result. Spend about half the answer on Action, and finish with a number or a change someone could verify.

• Situation, one sentence: "On the payments team, a week before a major launch...". Skip the company history.
• Task, one sentence: what your role in the story was - not the team's.
• Action, the core: what you decided and did, in the first person. "I", not "we" - they are hiring you, not your team.
• Result: what changed, with a number if you have one - latency, bugs, customers, hours saved. If the story ended badly, say what you learned and what you did differently next time.

Prepare five or six stories, not twenty answers. The same production-incident story can answer questions about pressure, mistakes and ownership - only the opening changes.

Which behavioral questions come up in tech companies?

Six questions you rarely hear outside tech and almost always hear inside it. For each: what it tests and a sample answer you can adapt.

"Tell me about a production incident you caused"

It tests ownership and transparency: do you admit the mistake, what did you do in the first minutes, and did you fix the cause, not just the symptom?

Sample answer: "I shipped a change to our caching layer that served stale data to some users. An alert caught it after twenty minutes; I rolled back and posted an update in the incident channel for the team and support. The next day I wrote a short post-mortem: my tests didn't cover a two-server setup. I added that test for every change to that layer, and we haven't had that class of incident since."

"Tell me about a technical disagreement with your manager or product"

It tests how you disagree - with data or with ego - and whether you can commit to a decision you didn't like. The best story doesn't end with you being right; it ends with a decision made well.

Sample answer: "Our product manager wanted to launch without a rollback path to hit the date. I thought it was risky, so instead of arguing I wrote up the trade-off: half a day of extra work against the risk of a payments outage. We took it to the team lead together and moved the launch by a day. Another time, on a different call, the decision went against me - I built it as decided and documented the risk."

"How do you decide between tech debt and new features?"

It tests business judgment: do you see tech debt as an economic decision rather than a matter of taste? Give the principle, then an example.

Sample answer: "I push for tech debt when it slows us down measurably. On my last team, any change to the permissions module took three days instead of one because it had no tests. I showed the numbers to my lead, we got two weeks to add tests and split the module, and changes there dropped to about half a day."

"Tell me about a code review you disagreed with"

It tests how you handle criticism in both directions. A good answer shows you separate the code from the person and can change your mind.

Sample answer: "A senior engineer asked me to rewrite a function I thought was fine. Instead of replying in the thread, I asked for a ten-minute call. It turned out he'd spotted an edge case I'd missed - he was half right and so was I. Since then I move long review debates out of comments and into a short conversation."

"Why move from a startup to a large company (or the other way)?"

It tests whether you know what you want or are just running away. A strong answer talks about what you'll gain, not what's wrong with your current job.

Sample answer: "In three years at a startup I built a lot from scratch, but I almost never worked on a system under real load. Your product serves millions of users, and those are exactly the problems I want to learn to solve."

"How do you work with product and design?"

It tests whether you understand the user and not just the ticket. Give an example where you asked "why" before "how" and changed something small because of it.

Sample answer: "I got a ticket to add an Excel export. I asked our PM what users did with the file, and it turned out they copied one number out of it. Instead of an export we built a card showing that number on the main screen - one day of work instead of three."

What should you avoid saying in an HR interview?

Don't criticize a former employer, don't give a theory instead of a story, and don't hide behind the team. Those three make interviewers write "no" even when the content of the answer is right.

• "I usually..." instead of "One time...": a behavioral question asks for one case. A general answer sounds like someone who doesn't have one.
• "We did..." throughout: the interviewer can't tell what you contributed.
• A story with no ending: without a result or a lesson, it doesn't answer the question.
• Criticism of a former manager, even when deserved: it says more about you than about them.
• Answers longer than five minutes: after three, the interviewer is already waiting for the next question.

How do you prepare for an HR interview in a day?

Write five or six STAR stories, rehearse them out loud, and prepare short answers on motivation, salary and notice period. Three to four focused hours are enough.

• Hour one: a list of stories - an incident, a disagreement, a win, a mistake, something you taught yourself, working with another team.
• Hour two: five lines of STAR for each story, with one measurable result.
• Hour three: say each story out loud and time it. If it runs past three minutes, cut the Situation.
• Last: one sentence on why this company, a salary range you've researched, and two questions of your own. For how to state the range, see our guide to tech salary negotiation.

If practicing with another person is hard, an interview-prep tool helps. Custro has an AI mock interview that gives feedback on your answers (part of the Pro plan) - but recording yourself on your phone does most of the work too.