مهارت مصاحبه و مسیر شغلیInterview Craft & Career

You can design a distributed system correctly, reason about the JMM, and rescue a slow query by reading its execution plan — and still get rejected. Not because you know too little, but because nobody ever taught you the other half of the job: what exactly the person across the table is looking for in each round, how to narrate work you have already done so its value is visible, how to avoid losing points when you get stuck, and how to talk about money without damaging the relationship.

This chapter is that other half, and it is treated exactly as seriously as the technical chapters. It is not motivational fluff and it is not a bag of rootless tricks. Like every other chapter, we start with a mental model, then build structure, then write real usable sentences, and then look at where each one breaks in the real world.

One thing before we start: the goal here is not to fool an interviewer. If you don't have a skill, no phrasing saves you — and if it does, six months later you are trapped in a job you cannot succeed at. The goal is to reduce the gap between what you actually know and what is visible to others to zero. Most good engineers carry that gap, and it is exactly that gap that burns offers.

1. Why the non-code half of hiring is engineering too

Three facts this whole chapter rests on:

One — a bad hire is expensive. For the company, it costs months of salary, team time and damage to the codebase. For you, a bad job costs a year of your professional life. So this is not a win-lose game; both sides are looking for fit. That reframing also lowers anxiety: you are not the defendant, you are the other evaluator.

Two — interviewers cannot read minds. Anything you don't say out loud does not exist. If you considered three approaches in your head and picked one but only stated the result, you get no credit for "reasons about trade-offs". Seniority is almost always measured through externalised thinking, not through the final answer.

Three — every round measures the same thing: risk. Behind every question sits this question: "if we hire this person, what could go wrong?" Will they produce low-quality code? Will they go silent when stuck? Can they handle review? Will they stay calm when production is down? Will they leave in six months? Every good answer removes one of those risks.

2. What a backend hiring process actually looks like

Processes differ in the details but share a skeleton. Knowing that skeleton means knowing, at every moment, what is being measured right now — and that single thing changes outcomes more than any other technique in this chapter.

The hiring funnel and what each stage filters for — قیف استخدام و هدف هر مرحله.

flowchart TD
  A[Application / referral] --> B[Recruiter screen<br/>20-30 min]
  B --> C[Hiring manager call<br/>scope and motivation]
  C --> D{Coding assessment}
  D -->|Take-home| E[Async exercise + debrief]
  D -->|Live| F[Pair coding session]
  E --> G[Technical deep dive<br/>your stack, your past work]
  F --> G
  G --> H[System design round]
  H --> I[Behavioural / values round]
  I --> J[Final conversation + offer]
  J --> K[References and contract]

Don't memorise the table below; understand it. The "primary signal" column is literally what the evaluator writes in their feedback form.

3. Read the job posting like a spec

A job posting is a badly written engineering document: part real requirement, part wish, part copy-paste. The first skill is separating those three layers.

Rewrite the posting into three columns:

• Core: what appears in the job title, in the first two bullets of the responsibilities, and repeatedly during interviews. If the posting says "design and build REST services with Spring Boot and PostgreSQL", that is the core, and 70% of the questions come from there.
• Adjacent: tools the team uses but doesn't expect mastery in — for example "familiarity with Kubernetes". For these you need "a mental model plus one real, however small, experience".
• Wish list: the 15-technology laundry list that no human holds at depth. Missing several of these is not a reason to skip applying.

Extract three things from every posting and keep them in a file next to your resume: (1) the exact vocabulary they use (if they say "service-oriented" and you say "microservices", speaking their language helps — but only when you genuinely did the same thing); (2) the business domain (payments, logistics, health…), which tells you which NFRs are critical to them; (3) scale signals (users, transaction volume, engineer count), which tell you what to focus on in the design round.

4. The resume: from task list to impact

4.1 The impact-bullet formula

Write every bullet on this skeleton:

[action verb] + [what] + [how / with what] + [measurable result] + [why it mattered]

Three realistic bullets, before and after:

❌ Responsible for backend development of the ordering service.
✅ Rebuilt the order-submission path in Spring Boot, replacing
   synchronous fan-out calls with an event-driven flow on Kafka;
   p99 latency dropped from 2.4 s to 380 ms and checkout timeouts
   fell to near zero during peak hours.

❌ Worked on database performance.
✅ Cut the nightly settlement job from 6 h to 40 min by rewriting
   three N+1 access paths into set-based SQL and adding two covering
   indexes, which moved the job out of the business-hours window.

❌ Used Docker and Kubernetes.
✅ Containerised eight services and moved builds to a shared CI
   pipeline, reducing "works on my machine" defects and taking
   average deploy time from ~50 min of manual steps to 7 min.

Three subtleties are hiding in those examples: before-and-after numbers ("from 2.4 s to 380 ms") always beat a single number; the mechanism ("by replacing synchronous fan-out with an event-driven flow") proves you understand why it improved rather than that it improved by luck; and the business consequence ("moved the job out of business hours") shows you also speak the language of the person funding the work.

4.2 What gets a resume discarded

• More than two pages for under ten years of experience. The reader has no time.
• A 40-item technology list with no proficiency levels. When everything is on one line, nothing stands out — and worse, the interviewer is entitled to ask about any of it.
• Skill percentage bars. What does "Java: 90%" mean? Nothing. Delete them.
• The pronoun "we" in achievements. If your own contribution isn't explicit, evaluators conservatively assume it was small.
• Unexplained employment gaps. One sentence is enough; silence is worse than an explanation.
• The same resume for every posting. Tailoring means reordering and highlighting, not inventing experience.
• Odd file formats. Send a PDF with selectable text (not a scan) and name the file meaningfully: Firstname-Lastname-Backend-Engineer.pdf.

4.3 When you cannot show the code

Most serious backend work lives in private repositories under an NDA. That is a real obstacle, but it has a solution: you may not publish your employer's code or data, but you may talk publicly about the problem, the architecture and your decisions — as long as you strip client names, confidential figures and proprietary specifics.

Four strong substitutes:

1. A sanitised design note. One page: the problem, the constraints, two options considered, the choice and why, the outcome. No company name, no internal schematics. This document is gold in a design round.
2. A small public reconstruction. Rebuild the same problem shape with synthetic data in a small repository; 300 clean lines with tests beat a half-finished 5,000-line project.
3. Open-source contributions. Even one merged small PR signals "can work inside a foreign codebase and survive review".
4. Writing. One technical note about something you genuinely solved builds more credibility than ten resume lines.

4.4 The brag document

The biggest cause of weak resumes is forgetting. You cannot remember what you did eighteen months ago. The fix is a plain file you spend two minutes on every Friday — and which later feeds your performance review and promotion case.

# 2026-Q3 — work log

## Shipped
- Reworked retry policy in the payment adapter (idempotency key + capped
  exponential backoff). Duplicate charge tickets: 12/month -> 0 in 3 months.
- Split the monolithic `report` endpoint into a queued job + polling API.
  Request timeouts on the reports page went away; p95 6.1 s -> 220 ms.

## Influence / people
- Wrote the ADR for choosing outbox-based publishing over dual writes;
  adopted by two other teams.
- Onboarded a new joiner: paired 3x/week for a month, they shipped
  their first production change in week 2.

## Incidents
- 2026-08-02, partial outage 34 min: connection pool exhaustion after a
  slow downstream. I was on call, mitigated by lowering the pool timeout
  and shedding load; wrote the postmortem and the bulkhead follow-up.

## Learned / still weak
- Learned enough about query planner statistics to fix two bad plans.
- Weak: Kubernetes networking. Reading, but would not claim it in an interview.

Note the last section ("still weak"). It is for you, but it is also exactly what gives you a real, specific answer when an interviewer asks "what do you want to grow in?" instead of a canned one.

5. The screening call: thirty minutes most people waste

The first call is usually with a recruiter, not an engineer. They are not looking for technical depth; they are checking four things: does what you've done match the need, why are you looking, when are you available, and is your expectation inside their band. Take this call lightly and the best engineers get filtered right here.

Write your 90-second introduction in advance and read it aloud until it flows. Structure:

1. Now (15 s): what you do and at what scale. "Five years in backend; currently transactional services in Java and Spring Boot, team of eight, about 300 requests per second at peak."
2. Highlight (45 s): one or two concrete achievements with a number and a mechanism — the resume bullets you already built.
3. Direction (20 s): why this role. "I'm looking for a heavier data problem and a place where I get involved in design earlier than the coding stage."
4. Bridge (10 s): hand the ball back. "Which part would be most useful to expand on?"

6. The technical deep dive: how depth is actually shown

This round is usually about whatever you put on your resume. An experienced interviewer starts with a simple question and then climbs the depth ladder until they reach the edge of your knowledge. That is not cruelty; it is the only way to measure level. The critical point: reaching the edge is not failure — how you behave at the edge is what gets scored.

How one question escalates to find your ceiling — نردبان عمق یک سؤال.

flowchart LR
  Q1[What is it?<br/>definition] --> Q2[How does it work?<br/>mechanism]
  Q2 --> Q3[When does it fail?<br/>limits and edge cases]
  Q3 --> Q4[What would you choose instead?<br/>trade-offs]
  Q4 --> Q5[Have you hit this in production?<br/>lived experience]
  Q5 --> Q6[Beyond your knowledge<br/>honest boundary]

A four-layer answer pattern that almost always works: short definition → mechanism → failure mode → your own experience. For a question about connection pools: "A pool is a set of pre-opened connections, because each connection costs a TCP handshake and authentication. Mechanically, a requesting thread borrows a connection and waits up to a timeout if none is free. Where it breaks: if a downstream service slows down, connections aren't returned, the queue grows and the whole service stalls — meaning the problem is elsewhere but the symptom shows up here. I hit exactly that; our fix was lowering the timeout and separating the pool for critical paths."

6.1 The "I don't know" that still scores

A three-part formula:

State the boundary honestly → connect to the nearest thing you do know → say how you would find the answer.

Example: "I don't know the exact mechanism of X and I'd rather not guess. What I do know is that Y is the same family of problem, and there the trade-off is usually between latency and consistency; my first guess is that it's the same here. If I hit this today, I'd read the official documentation for that component first, then build a small experiment with synthetic load to observe the real behaviour, and I'd check with someone who has run it in production before deciding." Three strong signals: honesty, transferring knowledge across domains, and method.

7. The coding exercise: take-home versus live

7.1 Take-home delivery checklist

What actually earns points is not a clever algorithm; it is this:

• Exactly what was asked. Read the brief twice and honour the requested inputs and outputs literally.
• One-command run. If the evaluator can't start the project in two minutes, none of your code quality is seen.
• Meaningful tests — a handful that cover behaviour and edge cases, not twenty repetitive ones for getters and setters. (Tooling detail lives in the testing chapter; here we care about the signal.)
• Clean boundaries — domain, I/O and persistence separated so the reader can infer the architecture from the folder names.
• A short, honest README.

# Order intake service — take-home

## Run
    ./mvnw test        # unit + integration tests (Testcontainers)
    ./mvnw spring-boot:run
    curl -X POST localhost:8080/orders -H 'Content-Type: application/json' \
         -d '{"customerId":"c-1","items":[{"sku":"a-1","qty":2}]}'

## Design in one paragraph
HTTP layer is thin and only maps DTOs; all rules live in the domain package,
which has no framework imports. Persistence is behind a repository port so the
in-memory implementation used by tests and the JDBC one share a contract.

## Trade-offs I made deliberately
- Idempotency: implemented via a unique constraint on (customerId, requestId)
  rather than a distributed lock. Simpler, and correct for a single database.
- No pagination on GET /orders: out of scope for the stated 3-hour budget.
- Chose plain JDBC over an ORM here because the mapping is trivial; with more
  aggregates I would revisit that.

## What I would do next with more time
Error taxonomy + problem+json responses, load test the write path, and add a
retry policy with jitter around the payment adapter.

8. Live coding: a protocol, not a miracle

Live coding is not a pure skill assessment; it is a simulation of collaboration. The interviewer is imagining what two hours of pairing with you feels like. So talking is part of the solution, not a distraction from it.

8.1 The five phases

Phase 1 — Clarify (3–5 min). Never start typing immediately. Standard questions: how large is the input? Is it sorted? Can there be duplicates? What should invalid input do — throw or return a neutral value? Is memory constrained or is speed the priority? Will this be called from multiple threads? Then summarise in one sentence: "So the problem is …. Did I get that right?"

Phase 2 — Example and plan (3–5 min). Work one small example by hand, then state the approach in a sentence and estimate its time and memory complexity (complexity analysis lives in its own chapter; here the point is saying it out loud). If you know a simpler, slower approach, announce it: "The naive version is O(n²); I'll write that first so we have something correct, then improve it to O(n log n) if we have time." This move almost always scores, because it is real engineering behaviour.

Phase 3 — Code with narration. Use meaningful names, mark any edge case you haven't handled yet with a TODO and say it out loud, and explain why as you type. If you change direction, announce it: "The way I'm going this becomes two nested loops; I'll back up and do a single pass with a map."

Phase 4 — Test your own code. This is where most candidates lose points. After writing, walk three scenarios through the code out loud: the normal case, the empty/zero case, and the boundary case (largest value, duplicates, null). If you find a bug and fix it yourself, you score higher than someone who wrote it bug-free but never checked — because teams trust the person who audits their own work ruthlessly.

Phase 5 — Review and improve (2 min). Say what you'd add for production: input validation, structured logging, size limits, behaviour against hostile input.

A "finished" interview-grade solution — what you produce in phases 3 and 5:

import java.util.HashMap;
import java.util.Map;
import java.util.Objects;

/** Finds the first character that appears exactly once, or null if none. */
public final class FirstUnique {

    private FirstUnique() { }

    public static Character firstUnique(String input) {
        Objects.requireNonNull(input, "input");              // fail fast, documented contract
        Map<Character, Integer> counts = new HashMap<>();     // LinkedHashMap not needed: we rescan
        for (int i = 0; i < input.length(); i++) {
            counts.merge(input.charAt(i), 1, Integer::sum);   // O(n) pass 1
        }
        for (int i = 0; i < input.length(); i++) {            // O(n) pass 2 keeps original order
            char c = input.charAt(i);
            if (counts.get(c) == 1) {
                return c;
            }
        }
        return null;                                          // edge case: no unique char
    }
}

And the tests you read out loud in phase 4 — even naming them scores if you run out of time to write them:

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class FirstUniqueTest {

    @Test void returnsFirstNonRepeating() {
        assertEquals('c', FirstUnique.firstUnique("aabbcdc"));
    }

    @Test void returnsNullWhenEveryCharRepeats() {
        assertNull(FirstUnique.firstUnique("aabb"));
    }

    @Test void handlesEmptyInput() {
        assertNull(FirstUnique.firstUnique(""));
    }

    @Test void rejectsNull() {
        assertThrows(NullPointerException.class, () -> FirstUnique.firstUnique(null));
    }
}

8.2 When you get stuck: the recovery protocol

Getting stuck happens and costs nothing by itself; long silence is what costs. Rehearse this state machine until it becomes automatic:

The recovery state machine when you get stuck — ماشین حالت خروج از بن‌بست در کدنویسی زنده.

stateDiagram-v2
  [*] --> Coding
  Coding --> Stuck: no progress ~60s
  Stuck --> SayItOutLoud: name the blocker
  SayItOutLoud --> Simplify: solve a smaller version
  SayItOutLoud --> Example: walk a concrete example by hand
  Simplify --> Coding: brute force first, optimise later
  Example --> Coding: pattern spotted
  SayItOutLoud --> AskHint: ask a targeted question
  AskHint --> Coding
  Coding --> Done: tests pass
  Done --> [*]

Ready-made sentences for each state: "Let me think out loud for a second — my blocker is that I don't see how to handle duplicates without sorting." / "Let me solve the easier version first and assume the input is sorted." / "I'll walk a small example by hand to spot the pattern." / "Targeted question: do you expect the original order to be preserved, or doesn't it matter?" — a targeted question is far better than "can you give me a hint?", because it shows you know exactly where you are stuck.

8.3 If the live exercise is SQL

Many backend interviews include a short SQL exercise. A common shape: "give me the top three rows per category." The right tool is a window function — and saying out loud why not a correlated subquery is part of the score.

-- top 3 salaries per department, ties share a rank (DENSE_RANK)
SELECT department_id, employee_id, salary
FROM (
    SELECT department_id,
           employee_id,
           salary,
           DENSE_RANK() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rnk
    FROM employees
) ranked
WHERE rnk <= 3
ORDER BY department_id, salary DESC;

-- identical logic; Oracle has had analytic functions since 8i
SELECT department_id, employee_id, salary
FROM (
    SELECT department_id,
           employee_id,
           salary,
           DENSE_RANK() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rnk
    FROM employees
) ranked
WHERE rnk <= 3
ORDER BY department_id, salary DESC;

And when they ask "how do you know it isn't slow?", the correct answer points at the plan, not at intuition:

EXPLAIN (ANALYZE, BUFFERS) SELECT ... ;

EXPLAIN PLAN FOR SELECT ... ;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

9. The system design round: narration structure

Design content itself lives in the "system design fundamentals", "distributed systems theory" and "design walkthroughs" chapters. What we add here is different: time management and narration. Most failures in this round come not from lack of knowledge but from lack of structure — the candidate spends 35 minutes on the database choice and never reaches scaling or failure modes.

The time budget of a 45-minute design round — بودجه‌ی زمانی یک جلسه‌ی ۴۵ دقیقه‌ای.

flowchart LR
  R[Requirements<br/>5-8 min] --> E[Estimates<br/>3-5 min]
  E --> A[High-level design<br/>10-12 min]
  A --> D[Deep dive on 1-2 parts<br/>10-12 min]
  D --> F[Failure modes and scaling<br/>5-8 min]
  F --> W[Wrap up: trade-offs<br/>2-3 min]

10. The behavioural round: the STAR method

STAR stands for Situation, Task (your specific responsibility), Action (what you did) and Result — a framework used in behavioural interviewing since the 1970s, whose underlying logic is that past behaviour is the best predictor of future behaviour. That is why the questions start with "tell me about a time when …", not "what would you do if …".

The right time split: situation 15%, task 10%, action 50%, result 25%. Most people invert it and spend five minutes on the situation.

10.1 A story bank: cover every question with six stories

Instead of memorising answers to twenty questions, pick six real events from the last two years and write each one out fully. Almost any behavioural question can be re-narrated from one of these:

11. Narrating a real production incident convincingly

"Tell me about an outage you handled" is one of the highest-signal questions there is, because it simultaneously measures technical knowledge, composure, communication and cultural maturity. Your narration should mirror the real structure of an incident:

The incident lifecycle you narrate — چرخه‌ی زندگی یک incident.

stateDiagram-v2
  [*] --> Detect: alert or user report
  Detect --> Triage: severity, blast radius
  Triage --> Communicate: stakeholders informed
  Communicate --> Mitigate: stop the bleeding
  Mitigate --> Diagnose: find the real cause
  Diagnose --> Fix: durable change
  Fix --> Postmortem: blameless write-up
  Postmortem --> Prevent: action items with owners
  Prevent --> [*]

Three things turn the story from anecdote into evidence: separating mitigation from fix (first you stop the bleeding — rollback, shed load, kill a feature flag — and only then hunt the cause; someone who conflates the two reveals they haven't been in a real crisis); saying how you found out (an alert? a customer? if a customer, that's a finding in itself); and blameless language ("change X caused it", not "so-and-so broke it").

12. A decision you regret

This question isn't a trap, but most people ruin it: either with a fake regret ("I was too much of a perfectionist") or with a lesson-free disaster. A good answer has four parts: a specific decision, the reasonable rationale you had at the time (proving you weren't careless), the real cost, and the rule you built from it.

13. The questions you should ask

Every round ends with five to ten minutes for your questions. That block does two jobs: it is the last signal recorded about you, and it is your only real chance to learn what working there is like. A good question is one that doesn't accept a canned answer — instead of "is code quality important to you?" (everyone says yes), ask "when was the last time you delayed a release for quality reasons?".

14. English for technical interviews

If the interview is in English and English is your second language, you have two separate problems: vocabulary and composure. Vocabulary is solved by practice; composure is solved by structure.

Rule one: slow down. Slow clear English is infinitely better than fast tangled English — and the interviewer isn't grading your fluency anyway, they're trying to understand you. Rule two: use pre-rehearsed sentence patterns so your mental capacity goes to content instead of grammar.

15. Compensation: how ranges are built and how to talk about them

Mechanism first, because without it negotiation degenerates into haggling. Most structured companies have levels — engineer, senior, staff — and each level has a band with three points: minimum, midpoint, maximum. Where you land in the band usually comes from three things: the level the interviews voted for, internal equity relative to people doing the same work, and the budget for that headcount. Which means effective negotiation is often negotiating the level, not just the number; raising the level raises both the pay and the growth path.

The order of moves in a compensation conversation — ترتیب حرکت‌ها در گفتگوی حقوق.

sequenceDiagram
  participant C as Candidate
  participant R as Recruiter
  R->>C: What are your expectations?
  C->>R: Ask for the band for this level first
  R->>C: Shares range (or refuses)
  C->>R: Give a researched range, top-anchored
  Note over C,R: Interviews happen — value is established
  R->>C: Verbal offer
  C->>R: Thank you - may I see the full package in writing?
  C->>R: One clear, justified counter
  R->>C: Revised offer or firm no
  C->>R: Accept in writing, or decline gracefully

Two practical rules. First: as far as possible, let them give the number first. The polite line: "So we don't waste either of our time, could you tell me the band set for this level? I'm comfortable with a fair market range, and if it fits, let's continue." Second: if you must go first, give a range, not a point, build it from real research, and know that the bottom of your range is what you will get — so your floor must be a number you'd genuinely accept.

16. Red flags inside the interview itself

An interview is a behavioural sample of that company's culture. What you see here will be worse on an ordinary working day, not better.

• Disrespect for your time: lateness without apology, repeated rescheduling, or weeks of silence between rounds.
• An unprepared interviewer: hasn't read your resume and opens with "so, tell me about yourself" because they know nothing.
• Gotcha questions meant to humiliate: where the goal is showing superiority rather than measuring. Watch how they behave when you don't know something — that is a preview of being reviewed by them.
• Ambiguity about the role: every interviewer defines the position differently.
• No answers to operational questions: they can't describe what happens between commit and production, or whether automated tests exist.
• Artificial urgency: "we need your answer by tomorrow" is sales pressure, not a healthy hiring process.
• Repeatedly asking your current salary after you've said you'd rather discuss the value of the role.
• Free work: an exercise whose output is precisely a real feature of their product.

17. The final conversation, the offer, and leaving well

The final conversation is usually with a more senior manager and is less technical. Its measure is simple: do you know why you're here, and are you someone the team would want beside them in a hard meeting? Have three things ready: one sentence on what makes this problem interesting to you, one serious question about the direction of the product or team, and an honest summary of what you've learned and what you still don't know.

If you're rejected, send a short, ungrudging message and ask for feedback. Some companies won't give it (legal policy), but even those keep your name with a positive note, and six months later when a better-fitting role opens, that behaviour comes back to you. If you accept, close your other offers quickly and clearly — leaving people hanging has a reputational cost. And in your current job, honour the contractual notice period, write handover documentation, and work the last week like the first. The market is small, and today's colleague is tomorrow's interviewer or reference.

18. After you're hired: the path to senior

Getting hired is not the end of the game; it is the start of the period in which you build or lose credibility.

First 30 days — learn and build trust. Understand the system through the data path, not the diagram: follow one real request from ingress to database. Get the development environment running on day one, and wherever you get stuck, fix the setup document right there — that is your first useful, low-risk contribution. Ship one small but real change to production in your first week so you touch the whole delivery chain. Ask a lot of questions and write the answers somewhere others can see them.

60 days — independent contribution. Now deliver one medium piece end to end. The first time something breaks, your behaviour is more visible than your code: raise it early, don't minimise it, and fix it.

90 days and beyond — impact beyond your own tickets. Find the thing that repeatedly trips people up and close it (a flaky test, a manual deployment step, a missing runbook). This is where "good engineer" turns into "senior engineer".

The growth loop after you are hired — مسیر رشد بعد از استخدام.

stateDiagram-v2
  [*] --> Learn: ship small, ask a lot
  Learn --> Own: end-to-end delivery of a feature
  Own --> Influence: ADRs, reviews, design input
  Influence --> Multiply: mentoring, docs, tooling
  Multiply --> Track: brag doc, promo packet
  Track --> Own: bigger scope

Learning in public is easier than it sounds and has the highest return: after every hard problem you solve, write ten lines — the problem, what you tried that didn't work, what did. Internally it becomes team capital; publicly it becomes a citable track record. Mentoring is not merely teaching either; it is the fastest route to your own next level, because it forces you to make tacit knowledge explicit, and that is exactly where you discover what you never really understood.

19. Cheat sheet: interview week