Behavioral Interview

The interviewer checks whether you can give a short, relevant summary and why you fit this role. Answer in one to two minutes: present (your role, stack and current work), past (how you got here, one result), future (why this role is your next step). Tailor it: lead with what the vacancy asks for; skip school, hobbies and the full CV One result with a number: a faster cold start, a crash rate you cut Red flags: retelling the CV job by job, a five-minute monologue, nothing about what you want next Example Present: "Backend developer, three years with Go. I'm on a payments team: gRPC services, PostgreSQL, Kafka, and on-call." Past: "I came from PHP and rewrote our webhook service in Go; its p99 fell from 400 ms to 80 ms." Future: "I want systems with more load, and your platform has that traffic."

The interviewer checks your motivation and whether you would leave them for the same reason. Give one honest reason framed as moving toward something (harder problems, a bigger product, a stronger team), then name two specific things that draw you to this company. Toward, not away: "I've outgrown my tasks" or "I want more scale", never "my manager is useless" Specific about them: their product, stack, a blog post or a talk; "a great company" says nothing A layoff or a short job: say it plainly in one sentence and move on Red flags: badmouthing your employer, "only the money", knowing nothing about them Example "Our service handles a few hundred requests per second, and I want to learn what breaks at a hundred times that. Your platform runs Go at that scale, and your posts on Kafka consumers are why I applied."

The interviewer checks the scale of what you have built and what you personally did in the team. Use STAR: the situation and its problem, your task, the actions you took and why, and a measurable result. "I" for your part: "we" only for the team's work; you are scored on what you did One decision in depth: expect "why that and not X?" A number for the result: crash-free users, load time, conversion, tickets Red flags: technologies with no problem behind them, an architecture you cannot explain, the team's success as yours Example Situation: a PDF export ran inside the HTTP request and timed out for large accounts Task: I redesigned it Action: the handler queues a job, workers build the file, the client polls for status; jobs are idempotent, so a retry never builds a second report Result: export timeouts went from about 5% to zero

The interviewer checks self-awareness and honesty. Name two or three strengths that fit the role, each backed by a fact, and one real weakness that does not block the job, together with what you already do about it. Strengths with proof: a fact from your work, not adjectives like "responsible" A real weakness: speaking up in big meetings, asking for help late, little experience in an area the role does not centre on What you do about it: a habit that already works, so the answer ends on progress Red flags: "I have no weaknesses", a disguised boast ("I'm a perfectionist") Example Strength: "Profiling. pprof and traces are where I start when something is slow." Weakness: "My first design docs were too long to read. Now I write one page with the decision at the top."

The recruiter checks whether you fit the budget and know your market value. Name a researched range for your level and market, say whether it is gross or net, per month or per year, and add that the figure depends on the whole offer. Research first: surveys, similar vacancies, peers who changed jobs A real floor: offers land near the bottom, so name a number you accept Know the convention: gross per year internationally; net per month («на руки») in Russian-speaking markets Ask their range: normal here, and a growing number of employers must state it up front Red flags: "whatever you offer", a number from thin air, volunteering your current salary Example International: "For middle Go roles I'm looking at X to Y gross a year. What's your range?" Russian-speaking market: "I'm looking at X to Y a month after tax. What's your range?"

The interviewer checks your interest and what matters to you; "no questions" reads as indifference. Prepare three or four questions about the work itself (the team, how they ship, what success in this role looks like) and pick those that fit the person in front of you. The work: "What would I do in the first three months?", "Who reviews code, and how big is the team?" How they ship: release cadence, testing, on-call, tech debt and who decides about it Success: "How will you know after six months that I'm doing well?" Match the person: process for the team lead, product plans for the manager, conditions for the recruiter Red flags: no questions, asking about holidays in a technical round Example "What does on-call look like, and how often does it page at night?" "How do services talk to each other, and who owns the database?"

The interviewer checks how you debug: how you narrow a problem down, which tools you use and whether you fix the cause or the symptom. Tell it as STAR, with most of the time on the actions: your hypotheses, how you tested them, and what stops the bug from returning. Why it was hard: only on some devices, only under load, no stack trace; say it first The search, step by step: crash reports and logs, a profiler, a minimal reproduction, git bisect, the false leads you ruled out The root cause in one sentence: so the interviewer can follow it Prevention: a test, an alert or a lint rule added afterwards Red flags: a trivial typo, "I don't remember", a bug a colleague found, a fix you cannot explain Example Situation: a service's memory grew for three days until Kubernetes killed it with OOMKilled, and then the cycle repeated Task: find the leak Action: the heap profile looked normal, but the goroutine profile from pprof showed 200,000 goroutines blocked on a channel send. When a request timed out, the handler returned and nobody read the worker's result. I gave the channel a buffer of one, so the worker could always finish Result: the goroutine count went flat, and a goleak check now runs in the tests

The interviewer checks ownership: whether you admit the mistake, limit the damage fast and change the process so it does not happen again. Pick a real mistake with limited impact, tell it with STAR, and spend the last part on what you changed. Own it plainly: "I shipped", not "it got shipped"; no blaming QA or the reviewer who missed it Damage control first: who you told and how fast, the rollback or hotfix, how many users were hit Fix the system: a test, a CI check, a review rule or an alert; "I'll be more careful" is not a fix Red flags: "I don't make mistakes", a story where it was someone else's fault, a disaster with no lesson, a tiny typo chosen to look safe Example "I ran CREATE INDEX on a 40-million-row orders table in the middle of the day. In PostgreSQL that blocks writes until it finishes, so checkout failed for about six minutes. I cancelled the query, reported in the incident channel and rebuilt the index at night with CREATE INDEX CONCURRENTLY. Afterwards we added a migration linter (squawk) to CI, and it rejects index creation without CONCURRENTLY."

The interviewer checks how you act when production is on fire: mitigate first, communicate, find the cause, then learn from it without blame. Tell it in order: the alert, the first action that reduced the impact, who you told, the root cause and the postmortem's action items. Mitigate before diagnosing: roll back, switch off a flag, scale up, pause a job; the root cause can wait an hour Communicate on a schedule: an incident channel, a status update every 15 to 30 minutes, help asked for early Evidence over guesses: dashboards, traces and logs around the start, recent deploys and config changes A blameless postmortem: timeline, impact, why it happened, why it was not caught, three to five action items with owners Red flags: "I fixed it alone and told nobody", a postmortem that names a guilty person, action items nobody did Example "At 3 a.m. I was paged for p99 latency on the orders API: up from 120 ms to 4 s. The dashboards showed the database pool saturated, and the spike matched a nightly export job. I paused the job, and latency recovered in minutes. The job shared the API's connection pool and ran unbounded queries. In the postmortem we gave it its own small pool, added an alert on pool wait time and moved the export to a read replica."

The interviewer checks whether you can disagree without damaging the working relationship. Pick a real work disagreement, often a technical one or a code review, and show how you moved it from opinions to shared criteria, what was decided and how you worked together afterwards. Talk early and directly: move a long comment thread to a short call or a one-to-one Understand their side first: restate their position fairly before arguing yours Agree on criteria, then decide: numbers, team conventions, a quick prototype; if you still disagree, the decision's owner decides and you commit Losing is fine: a story where you accepted the other approach shows maturity Red flags: "I've never had a conflict", the colleague as a villain, going to the manager first, winning at the cost of the relationship Example "A colleague left thirty style comments on each of my PRs and held them for days. In a one-to-one I learned he had been burned by inconsistent code before. We agreed to move style rules into golangci-lint, mark the remaining nits as non-blocking and keep reviews within one working day. After that his reviews were about design, not formatting."

The interviewer checks whether you plan realistically and raise a risk as soon as you see it, not on the deadline day. Explain how you break work down and estimate, then tell a story where you saw a slip coming, told people early and offered options. Break it down: pieces of half a day to two days, including tests, review, QA and release, which people forget Unknowns separately: a time-boxed spike for anything new to you; give a range, not one number Compare with the past: how long similar tasks really took When it slips: tell the lead or PM the day you know, with options: cut scope, move the date, add help; never quietly work nights and hope Red flags: "I'm never late", an estimate with no breakdown, announcing the slip on release day Example "I estimated a payment provider integration at five days. On day two I found that their sandbox sent webhooks without signatures, unlike the docs. I told the lead that day, wrote to the provider's support, and proposed releasing behind a flag with status polling as a fallback. We shipped on the planned date with polling and switched to webhooks a week later."

The interviewer checks whether you think about the product and push back with arguments instead of silently building or refusing. Show that you asked about the goal, brought evidence of the cost, offered an alternative that reaches the same goal and accepted the final decision. Ask about the goal first: the requirement is often one way to reach it, and a cheaper way exists Bring evidence: a recording on a real device, a measurement, a platform guideline, an estimate for each option Offer an alternative: "Not X by Friday, but Y gives you most of it" Respect the decision: once the product owner decides with the trade-offs on the table, you build it well Red flags: "I just do what I'm told", refusing with no alternative, going over the PM's head Example "The PM asked for a dashboard that counted all orders since launch on every page load. On our data that query took about 8 seconds and would load the primary database. I asked what decision the numbers supported: they were checked once an hour. We built a summary table updated from order events every minute, and the page now loads in under 100 ms."

The interviewer checks whether you can hear criticism without getting defensive and tell a colleague about a problem without hurting them. Describe how you do both, and back it with one story where feedback changed how you work. Receiving: listen to the end, ask for a concrete example, thank them, and come back later with what you changed Giving: in private, soon after the event, about the behaviour and its effect rather than the person ("this PR had no tests, and the bug reached QA"), with a suggestion In code review: explain why, separate blocking issues from nits, say what is good Red flags: "I never get negative feedback", arguing with every point, feedback only through the manager, harsh public comments Example "After my first design review, a senior said my doc described the code but not the options I had rejected. Now every doc of mine has an 'Options considered' section, and reviews are shorter because the obvious questions are already answered."

The interviewer checks whether you multiply the team's output, not just your own. Tell a concrete story: what the person or the team struggled with, what you did regularly (pairing, review, gradually harder tasks, shared practices) and a result you can point to. Start from their gap: ask and watch what actually blocks them; a generic lecture does not help Teach through real work: pair on a task, then give a similar one to do alone; review with explanations and links instead of rewriting their code Grow independence: tasks a little above their level, and room for small mistakes where they are cheap Scale it to the team: a checklist, a lint rule, a PR template, a short internal talk, written decisions A result: they shipped a feature alone, review rounds fell, onboarding got shorter Red flags: "I just fix their code myself", mentoring as giving orders, no example Example "A junior started goroutines with no way to stop them and passed context.Background() deep into the code. We went through the request lifecycle together on his PRs, and I wrote a short review checklist: ctx as the first parameter, errors wrapped with %w, every goroutine has an owner. We also turned on -race in CI. Three months later he built the next small service on his own."

The interviewer checks whether you speak the business's language and prioritise, instead of asking for a rewrite. Translate the debt into a cost the business already feels (slower features, incidents, lost users), propose a small, measurable plan and report the result. Measure the pain: time to ship a typical feature, bugs per release in that area, incidents, build time multiplied by the team Prioritise by cost: debt in code that changes often matters; old stable code can stay ugly Small and continuous: a fixed share of each sprint, or the cleanup bundled with the next feature in that area, not a three-month freeze Report the effect: numbers before and after make the next request easier Red flags: "the code is ugly" as the argument, asking for a full rewrite, hiding the work inside feature estimates Example "The billing service had no tests and a shared utils package that everyone touched. Four of our last six incidents started there. I proposed a rule, no change to billing without tests for the code it touches, plus one day per sprint for splitting the package. A quarter later billing had no incidents, and changes there no longer needed two reviewers."

The interviewer checks whether you make architecture decisions by criteria and record them, rather than by taste or the loudest voice. Show the options, the constraints you agreed on, how the decision was made and written down, and what happened after. Name the real constraints: team size, consistency (must it share a transaction with orders?), load, operating cost, who will be on call for it Write it down: a short design doc or ADR with options, trade-offs and the decision; comments arrive in writing before the meeting Prefer reversible steps: a module with a clear interface inside the monolith can become a service later, while a split is hard to undo Disagree and commit: once it is decided you build it well, and you name the signal that would reopen it Red flags: "microservices because everyone has them", a new database because you wanted to try it, refusing to commit after losing Example "The team wanted notifications as a new service on MongoDB. I argued for a module in our Go monolith on PostgreSQL: we were four developers, and notifications had to be written in the same transaction as orders. I wrote a one-page ADR with both options; we chose the module with an outbox table and agreed to revisit at ten times the volume. A year later it still runs inside the monolith with no consistency bugs."

The interviewer checks whether you treat reliability as a project: measuring before changing, finding the real bottleneck, protecting the service from overload and coordinating with other teams. Tell it with STAR, with numbers before and after. Know the target: the expected peak in requests per second, and the latency and error rate you must keep Load test first: k6 or replayed production traffic against a staging copy, with pprof profiles and database metrics Fix the bottleneck you found: often the database (indexes, pool size, caching), not Go itself Protect the service: a timeout on every call, rate limiting, a circuit breaker on slow dependencies, a degraded mode Coordinate: owners of the downstream services and the database get the same numbers before the day Red flags: "we added more pods" as the whole story, optimising without measuring, no idea what fails first Example "Before a sales event we expected five times our usual 800 requests per second. A k6 test showed p99 above 2 s at 2,000 rps: every request ran the same product query. We cached product data in Redis for 30 seconds, set timeouts and a circuit breaker on the slow recommendations service, and served the page without recommendations when it failed. On the day we peaked at 3,600 rps with p99 under 250 ms."