Behavioural Questions, Salary and Offers

I keep it positive and about the future. "I have enjoyed my time here. In four years I moved from small tickets to owning our reporting service. I have learned most of what I can in this setup, and I want to work with a larger engineering team and a harder scale problem. When I read about this role, it matched that." I do not mention my manager or pay unless the pay is a real, calm part of it. If they ask directly about pay, I say "pay is part of it, as it is for anyone, but the main reason is the scope of the work".

Follow-up: "What if the real reason is a bad manager?" I say what I wanted instead: "I want more regular feedback and clear goals." That is honest and does not blame.

I use present, past, future in about one minute. "Right now I am a full-stack engineer on a product team, mostly TypeScript, Next.js and Node with MongoDB. I own our reporting feature, from the API to the screen. Before that I built an admin dashboard and learned about indexes and caching the hard way. I am looking for a team where I can keep working across the stack and help others grow." I finish with a link to the role. I do not read my CV and I do not start from school.

I give one real fact about them and one reason it fits me. "I read your engineering post about moving search to its own service. I have done a similar job with Meilisearch, and I liked how you wrote about the trade-offs. I would like to work on a product where search quality matters." If I am honest that I have only a little knowledge of them, I say what I did learn and ask a question. I never say only "great culture" or "good salary".

I state the fact, what I did, and that I am ready. "My team was part of a company-wide reduction in March. After that I took two months to rest and to finish a course on testing, and I built a small app with Next.js and Prisma to practise. I am ready to start now." I do not complain about the company and I do not apologise too much. Layoffs are a known part of the industry, and a calm answer shows maturity.

"A teammate and I disagreed on how to store notification settings. I wanted a separate collection; they wanted to put it inside the user document. Both of us wanted a quick launch and few bugs, and I said that first. I asked them to explain their worry. It was the extra database call on every login. I showed the numbers from a quick test: the extra read was small with an index. They showed me that settings were always read with the user. We agreed on a hybrid: a small embedded object for the common flags, and a separate collection for history. We shipped on time. Afterwards I started asking 'what is your biggest worry?' at the start of design talks." The shape is: shared goal, listen, evidence, agreement, lesson. I never make the other person the villain.

"Our manager decided to launch a feature without a rollback plan to meet a date. I thought the risk was too high because it changed data in the database. I asked for ten minutes and wrote down three points: what could break, how long it would take to fix without a plan, and a small plan that took half a day (a feature flag and a backup). He listened and still wanted to keep the date, so we added the flag only. I agreed because it was his call and the risk was now small. The launch had one bug, and the flag let us turn it off in two minutes." The key sentence is "I disagreed, I gave evidence, then I committed to the decision." Interviewers want to hear that I can disagree and still support the team.

Follow-up: "What if you were still sure it was wrong?" I say I would put my concern in writing, respect the decision, and watch for the risk, but I would escalate only for real harm like security or legal risk.

"I ran a database script on production that updated more users than I meant, because I tested the filter on staging data that looked different. About 300 users got the wrong plan name. I saw it within five minutes in the logs, told my lead and the support team straight away, and restored the values from the backup. I wrote a short post-incident note without blame. Afterwards I added a dry-run mode that prints the count first, and a rule that any production script has a second reader." I own it in the first sentence, I tell people early, and I show a change that stops it for everyone. If the story has no lesson, it is a bad story. Avoid "I never make mistakes" and avoid a fake weakness like "I work too hard".

"I estimated two weeks for a CSV import feature and by day six I saw that the file formats from customers were much messier than the sample. I told the product manager the same day, with two options: ship a limited version for the two clean formats on time, or ship all formats one week late. They chose the limited version first. We shipped on the date, and the rest followed the next week. Since then I look at real customer data before I estimate, and I give a range." The point: I raised the risk early and offered options, rather than being silent until the date.

"I try to understand the user problem before the solution. If a request is expensive, I show options with cost and risk in simple words, for example: 'the full version is about three weeks; this smaller version is one week and covers most users'. With designers I ask to see designs early, before they are final, so I can point out what is hard (such as a layout that needs a lot of extra requests) while it is still cheap to change. I also say 'no' with an alternative. I write down decisions so we do not argue later about what was agreed."

"I do three things. First, I give a junior a real, small, safe task and tell them why it matters. Second, I review their code with questions, not orders: 'what happens here if the list is empty?'. Third, I pair for 30 minutes on the hardest part and then step back. Once a new engineer kept getting the same React state bug. I explained how renders work with a small example, and in a month they were fixing similar bugs for others. I measure success by how much they can do without me." The trap: "I do it myself because it is faster". That says you cannot grow a team.

"The request was 'make search better'. That is not a task. I asked who was unhappy and with what. I read support tickets and found that users typed a product name with a spelling mistake and got no results. I wrote my assumptions and a goal, agreed it with the product manager, and shipped a first small change: typo tolerance on product names. I measured how many searches had zero results before and after, and then we chose the next step with real data." The steps: ask, find the real problem, write assumptions, ship small, measure.

"I look at impact, urgency, effort and risk. A broken payment page for all users beats a nice change for one customer. I make my list visible to people who depend on it. If two stakeholders both say 'urgent', I do not choose silently; I show them both items and the cost of the delay and ask them, or our manager, to decide the order. I protect time for incidents. Then I say 'no' or 'later' clearly, so people can plan." Interviewers like to hear that I can say no with reasons and I do not just work longer hours.

I prepare five and use three or four. "What does a good first three months look like in this role?" "How does the team handle releases and production problems?" "What was the hardest thing the team shipped last year, and what did you learn?" "How are disagreements about design settled?" "Why is the role open?" I write answers down. I ask the engineers about the work, and the manager about growth and goals. I avoid asking only about leave in a first call. If I am asked "any more questions?" and I say "no", that can look like I do not care.

I try not to give the first number. If a recruiter asks early, I say: "I would like to understand the role and the level first. Can you share the range for this position?" Many companies will. If they insist, I give a range based on market data and say it depends on the total package: "Based on what I see for this level and city, I am looking at X to Y, and I am flexible depending on the whole package." I make sure the bottom of my range is a number I would accept. I do not lie about my current pay. If asked about it, I say I prefer to focus on the market value for this role. Where rules or a form require it, I answer honestly and calmly.

I compare total compensation, not just base pay. I put both offers in a table: base, bonus (how sure is it), equity (what vesting, can I sell), benefits, leave, remote policy, notice, sign-on. Then I add the non-money parts: the work, the team, my manager, growth, stability of the company, and commute or time zone. I treat private-company equity as uncertain; I count it low unless I know the facts. I ask the company to put each offer in writing so I compare real terms. Pay is one part of the decision, not all of it.

I wait for the offer in writing, say thanks, and ask for a day or two. I show I am excited, because that is true and it helps. Then I make one clear request with reasons: "I am very excited about the team. Based on my scope (owning X) and market data for this level, I was hoping for a base of Y. Is there room to move towards that?" If base cannot move, I ask about other parts: a sign-on bonus, a review date in six months, equity, or the level. The sign-on bonus happens only once, so I ask before I accept. I do not threaten, and I do not make up another offer. After a final answer I decide kindly.

Follow-up: "What if they say the offer is final?" I ask once, politely, what else can change (start date, sign-on, review). If nothing can, I decide on the offer as it is. I do not push again.

I use it only if it is real and I say the facts. "I have another offer with a higher base and it expires on Friday. I prefer your team, so I want to see if we can close the gap." I tell the other company too, if I want to speed up their process, because timing matters in hiring. I do not exaggerate numbers, and I do not play companies against each other. If a company matches, I must be ready to say yes, because asking when I would never accept wastes everyone's time and my name.

I stop and ask why I wanted to leave. If the reason was pay only, and I like the work, a counter-offer may be right. But if the reason was growth, the manager or the project, a raise usually does not change that. I also think about how it feels that I had to resign to get a raise. I decide with the same table I used for offers. If I stay, I tell the other company kindly and early. If I go, I say thanks to my manager and keep the relationship good. (This is opinion: some people stay and are happy. The point is to decide with a clear reason, not with a quick feeling.)

I choose two or three people who saw my real work: a former manager, a tech lead, and a teammate. I ask them first, send my CV and the job description, and tell them what I hope they can speak about. I do not give a name without permission. If my last manager is a risk, I offer other people who saw my work and I explain it plainly: "We had different views on direction, but my tech lead worked with me every day." I say thanks to them after.

"In the first month I would learn: set up my machine, read the main code paths, meet the team and the product manager, fix one or two small bugs so I go through a full release, and write down what confused me in the docs. In the second month I would own a small feature and join code review and on-call training. In the third I would deliver a bigger piece and suggest one improvement based on what I saw, then agree goals with my manager. I would not try to change everything early. I would first understand why things are the way they are." The trap: promising big changes before you know the system.