Skip to content

Behavioral interview · Recruiter screen, motivation and closing

The first filter and the last conversation. Both are underrated: a lot of very good people fail the 20-minute recruiter call, and many accept worse offers than they could because they don’t know how to negotiate.


Part 1 · The initial screen (20–30 minutes)

Section titled “Part 1 · The initial screen (20–30 minutes)”

The caller usually isn’t technical. Their job is to filter: role fit, salary expectations, availability and red flags. Your job here is not to rule yourself out, not to show off.

Q1. Tell me a bit about yourself and your experience

Section titled “Q1. Tell me a bit about yourself and your experience”

❌ What NOT to say

“I work with Java 17, Spring Boot, Kafka, Kubernetes, and we’ve migrated to a hexagonal architecture with event sourcing…”

Why it’s wrong: you’re speaking a language your listener doesn’t share. They can’t evaluate any of it, so the only thing they record is “can’t adapt to the audience” — which is a competency they can evaluate.

⚠️ Acceptable answer

“I’m a backend developer with six years of experience, mainly in Java. I’ve worked in logistics and e-commerce companies.”

What it’s missing: the kind of problem you solve and why this role. Correct and unmemorable.

✅ Ideal answer

“I’m a backend developer with six years of experience. I work on the systems that process orders and payments — the part that has to work, because if it fails the company stops billing. In my current role I make sure that part is fast and reliable: the last big project was redesigning the payments flow, and we went from monthly incidents to none in six months. This role interests me because, from what I read, you’re growing fast in volume, and that’s exactly the kind of problem I enjoy.”

Why it works: business-language impact, no jargon, a concrete result, and a connection to the company. A non-technical person can repeat this to the hiring manager — which is exactly what you need.

🔁 Likely follow-up: “And which technologies?” → Now yes, the list, short and grouped: “mainly Java and Spring with Postgres and Kafka; and I’m comfortable with Kubernetes for deploying and debugging my services.”


What they assess: whether you’re within band — and, incidentally, how prepared you are.

❌ What NOT to say

“I currently earn X, so a bit more would be fine.” (or) “Whatever you offer, I’m flexible.”

Why it’s wrong: anchoring on your current salary gives away all your leverage, especially if you were underpaid; and “whatever you offer” invites the bottom of the band and signals you don’t value your work. In many places, asking about current salary isn’t even legal any more.

⚠️ Acceptable answer

“I’m looking for around X, though it depends on the full package and the responsibilities.”

What it’s missing: justification, and an attempt to make them go first.

✅ Ideal answer

“Before I give a number — can you tell me the band you have budgeted for this role? That way we quickly see whether it makes sense to continue. (If they insist:) For a senior role with this scope, and based on what I’m seeing in the market, my range is between X and Y, and I move within it depending on the full package: bonus, contract type, remote setup and learning budget. If we’re in the same territory, we can work out the rest calmly.”

Why it works: tries to make them go first, and otherwise gives a range justified by market and scope rather than by your current pay — and opens the conversation to the full package.

🔁 Likely follow-up: “What do you earn now?” → “I’d rather not anchor the conversation there; what matters to me is that the range matches what I bring and what you need.” Said pleasantly, it works and doesn’t offend.

If you work from Latin America for a foreign company: ask explicitly about the contracting model (local payroll, contractor, employer of record), who bears taxes and currency-conversion fees, and which currency you’re paid in. That detail moves your net pay more than a 5% base difference.


Q3. Why do you want to leave your current company?

Section titled “Q3. Why do you want to leave your current company?”

What they assess: red flags. It’s a risk question, not curiosity.

❌ What NOT to say

“The environment is terrible, my manager has no clue, and the codebase is a disaster nobody wants to fix.”

Why it’s wrong: even if all of it is true, the interviewer can only conclude one thing: in two years you’ll talk about them that way. It also suggests you never tried to change anything. Criticism of third parties is free and everyone discounts it.

⚠️ Acceptable answer

“I’m looking for a new challenge; I’m not learning as much as I used to in my current role.”

What it’s missing: specifics. It’s generic enough to sound like a rehearsed excuse.

✅ Ideal answer

“I’ve learned a lot there, especially about reliability and working with legacy systems. What I want next isn’t available: the product is in a stable phase with little new volume, and what drives me is scale and data problems. I’m also looking for an environment where engineering has more weight in product decisions, which is something I saw here from the way you describe it.”

Why it works: talks about where they’re going, not what they’re fleeing; acknowledges what they learned; connects to the company. Nobody comes off badly.

🔁 Likely follow-up: “What if your company counter-offers?” → “If my reason were money, that would make sense; since it’s the type of problem I want to work on, a counter-offer doesn’t change it.” (And that’s true: accepting counter-offers usually ends badly.)


What they assess: genuine interest. A cheap filter that a lot of people fail.

❌ What NOT to say

“Honestly I haven’t had time to look much into it, but the offer seemed interesting.”

Why it’s wrong: it says you’re mass-applying. If you didn’t spend 15 minutes, why would they spend five interviews on you?

⚠️ Acceptable answer

“I know you’re a logistics company operating in several countries and that you’re growing a lot.”

What it’s missing: anything that isn’t the first line of their website.

✅ Ideal answer

“You’re a logistics platform for e-commerce in the region, and from the job description I understood the current challenge is volume: more orders, more carrier integrations and real-time tracking. I also read a couple of posts on your engineering blog about moving shipment tracking to events, which is a problem I’ve lived from the other side. And one thing caught my attention that I wanted to ask you: how are you handling the carrier integrations, which are usually the most unpredictable part?”

Why it works: specific research, connects to their experience, and closes with a question that opens a conversation. It changes the tone of the call entirely.


What they assess: whether your motivation matches what the role actually offers.

❌ What NOT to say

“Working with modern technologies and constantly learning new things.”

Why it’s wrong: it’s everyone’s default answer, and it worries them: in any real company a good part of the work is maintaining what exists. If your motivation depends on new technology, they’ll assume you’ll be bored in six months.

⚠️ Acceptable answer

“I’m motivated by solving complex problems and by what I build having an impact on users.”

What it’s missing: an example that makes it credible.

✅ Ideal answer

“Two things. First, that what I build gets used and noticed: I enjoy fixing something that affects thousands of people a day far more than building the most elegant feature nobody uses. Second, understanding complicated systems: I love the moment when a problem that looked like black magic turns out to have a concrete explanation. That’s why I like production problems so much. Learning matters to me, of course, but not for the sake of new technology — for being able to solve things I can’t solve today.”

Why it works: specific, credible, and it qualifies the “I want to learn” so it doesn’t read as an escape from maintenance.


Q6. How do you work in a team / how do you like to be managed?

Section titled “Q6. How do you work in a team / how do you like to be managed?”

What they assess: real cultural fit, and whether you’re aware of your own style.

❌ What NOT to say

“I adapt to anything, I have no preferences, I can work any way.”

Why it’s wrong: either you don’t know yourself, or you’re saying what you think they want to hear. It’s also counterproductive: if you end up somewhere that doesn’t fit, you’ll suffer and so will they. This question is as much yours as theirs.

⚠️ Acceptable answer

“I prefer a collaborative environment, open communication and autonomy to organise my work.”

What it’s missing: specifics. “Collaborative” and “open” mean different things at every company.

✅ Ideal answer

“I work best with context and autonomy: give me the problem and the why, and let me propose the how; conversely, if I get pre-chopped tasks with no context, I perform noticeably worse. I like frequent, direct feedback, and I’d rather hear things early even if they’re uncomfortable. In a team I’m a writer: I put decisions and designs in writing, because remotely that’s what stops people depending on being in the same meeting. And something I know about myself: I ask a lot at the start, more than seems necessary, because I’d rather understand the domain before touching it. If your team works very differently from this, I’d rather know — fit matters as much as the technical side.”

Why it works: describes their style with examples, admits something real about themselves, and treats fit as a mutual decision.


What they assess: interest, judgment and what you pay attention to. It’s the last impression and the most remembered.

❌ What NOT to say

“No, I think everything was clear, thanks.”

Why it’s wrong: after an hour discussing a job that will take eight hours a day for years, having no curiosity reads as disinterest — or as someone who’d accept anything. It’s a free mistake and surprisingly common.

⚠️ Acceptable answer

“What’s the team’s day-to-day like? What methodology do you use?”

What it’s missing: depth. Those are answered by a brochure.

✅ Ideal answer — pick 4 or 5

About the real work

  • How long does a small change take today from decision to production?
  • What share of time goes to new features, maintenance and incidents?

About quality and reliability

  • What’s on-call like? How many night alerts last month?
  • Do you run postmortems? What came out of the last one?

About the role

  • What would you expect someone joining to have achieved after six months?
  • What distinguishes a senior from a staff engineer here?
  • What’s the team’s biggest technical risk right now?

And the best closing question

  • “Is there anything about my profile that gives you doubts, that I could clarify now?”

Why it works: the answers give you real information to decide with, and the questions position you as someone who has worked in serious places. The last one lets you address the objection that would otherwise go unanswered and decide the outcome.

🔁 Watch out: listen to the answers. If they tell you they don’t do postmortems, deploy monthly and on-call is brutal, you’ve just obtained the most valuable information of the whole process.


❌ What NOT to do

Accept on the call, thrilled, without seeing anything in writing.

Why it’s wrong: you lose the only real negotiation window, which is between the offer and your yes. And without the written detail you don’t know what you’re accepting: bonus against which targets, equity at what valuation and vesting, what happens with taxes.

⚠️ Acceptable

“Thanks, I’ll think about it and let you know.” (and nothing else)

What it’s missing: using the moment to request full detail and leave the door open to negotiate.

✅ Ideal

“Thank you, I’m really pleased and I’m genuinely interested in the role. Could you send it in writing with the full package — base, bonus and how it’s calculated, equity if any with valuation and vesting, and the contracting model? I’ll review it carefully and come back to you in a couple of days. If anything needs adjusting, I’d rather tell you once, with reasons, than go back and forth.”

And if you’re going to negotiate, do it once, with a concrete reason:

“Everything fits and I want to move forward. The only piece I’d like to revisit is the base: given the scope of the role — which includes leading the migration — and what I’m seeing in the market for equivalent positions, X would work for me. If you can get there, I’ll sign today.”

Why it works: genuine enthusiasm, request for detail, a single justified adjustment, and a clear close (“if you get there, I sign”) — which is what settles many negotiations in your favour.

🔁 Rules not to break

  • No ultimatums and no inventing offers you don’t have: it gets checked and everything collapses.
  • Don’t resign from your current job until the contract is signed.
  • If they pressure you to answer in 24 hours “or it’s gone”, that’s a signal about how they treat people internally.

When What
Same day Write down what they asked and what you answered weakly: that’s your personalised bank
< 24 h Short thank-you note mentioning something concrete from the conversation
If rejected Ask for specific feedback: “which area did you expect more depth in?”
Always Update your progress tracker with the gaps you found