In this article
Before you start
This page is part of the behavioral interview questions guide. Everything below about the round itself is reported by candidates, not stated by LinkedIn; the engineering content comes from published sources.
Why interviewers ask this
A craftsmanship round decides whether a senior candidate can be trusted with the quality of a whole team's work, which is a different bar from solving a coding problem. One candidate report lists a Staff craftsmanship round of 60 minutes among six onsite rounds. Candidates list craftsmanship beside host manager, coding and algorithm, lunch, system design, and coding and implementation rounds. The same report says the Staff background phone interview listed "Leadership, Execution, Craftsmanship" as focus areas.
Reported topics are project metrics, continuous integration (CI) and continuous delivery (CD), and best practices and how to weigh solutions. A weak answer names tools. A strong answer defines quality in measurable terms, orders the work by evidence and says what each choice costs.
Text description of the diagram
- Candidates list craftsmanship beside host manager, coding and algorithm, lunch, system design, and coding and implementation rounds.
- One candidate report lists a Staff craftsmanship round of 60 minutes among six onsite rounds.
LinkedIn's craftsmanship round from first principles
- Craftsmanship round
- A craftsmanship round is an interview round, reported by candidates for LinkedIn senior and Staff roles, in which the interviewer asks situational questions about engineering practice, such as code review, monitoring, testing, mentoring and legacy systems, to judge how well the candidate builds and maintains quality software. LinkedIn has not published a definition, so this description rests on candidate reports.
- Golden signal
- A golden signal is one of four measurements, latency, traffic, errors and saturation, that Google's monitoring chapter names as the core of monitoring a service. Together they tell an engineer whether users are being served and how close the system is to its limits.
- Strangler fig pattern
- The strangler fig pattern is a way of replacing a legacy system by gradually extracting features into a new application built around the old one, until the old system can be safely decommissioned. It does not require microservices.
In plain words
Think of a head chef asked how to keep a busy kitchen producing good food. The chef is not asked to cook a dish. The question is how they would run the kitchen when new cooks arrive and the oven is old. They would check what comes out, watch for delays and fix the worst problem first. The analogy breaks in one place. A software team cannot close the kitchen to rebuild it, because customers keep arriving while the changes ship.
In one precise sentence, the round asks you to show engineering judgment: define quality in measurable terms, make problems visible, protect every change and replace risky parts in small steps. The four steps below follow that order.
Step 1: Define quality and success for the service
Quality in a craftsmanship answer means how the service behaves for users and operators, measured in numbers, not a feeling about clean code. The standard measurement set is the four golden signals: latency, traffic, errors and saturation, from Google's monitoring chapter. The same chapter says a monitoring system should answer what is broken and why.
Reported questions include how you define a quality product or system and what you look for to judge a service's success. A strong answer names the four signals, adds a service level objective, and says that any request slower than a committed limit is an error. The chapter's own example is that if you committed to one-second responses, any request over one second counts as an error. Then add the human side: changes are small, reviewed and reversible. Input: a service and its users. Output: a short list of numbers and a target for each. You now have a definition you can measure.
Step 2: Make the legacy system visible before fixing it
A legacy application with no monitoring cannot be prioritized, because nobody can see which problem hurts users most. Measurement therefore comes before fixes. Tail latency is the response time of the slowest small share of requests, and it is what monitoring must show, because averages hide it. In the chapter's example, a service with a 100 millisecond average at 1,000 requests per second can still have 1% of requests taking 5 seconds; the worked example below computes what that means.1
So instrument the four signals, read p99 rather than the mean, and alert on symptoms users feel. The chapter notes that a 99th-percentile reading over a small window, such as one minute, can give a very early signal of saturation. It also says effective alerting has good signal and very low noise, which means few pages and each one real. Record every push, meaning any change to running software or configuration, so a regression can be matched to a change. Input: an unmonitored service. Output: dashboards, a few alerts and a change log.
Step 3: Protect change with tests and code review
Once the system is visible, make each change safe. Add tests around the riskiest paths first, usually tests that record what the legacy code does today, and keep a way to roll back a release. Code review helps, but LinkedIn's engineering post says most review feedback is not about defects, so review is not a substitute for testing. It says review spreads knowledge and helps scale code ownership, and that review participation is mandatory at LinkedIn.
The post names large changes as the main issue faced by maintainers. It reports guidance that a change should be kept to around 200 lines of code (LOC) and not exceed 400. It also calls a standard review system a culture change, not just a process change. Input: a risky codebase. Output: a safety net of tests plus small, reviewed changes.
Step 4: Migrate to microservices in slices
Replace the monolith gradually; do not rewrite it in one go. The strangler fig pattern moves to microservices by gradually extracting features and building a new application around the existing system, and the monolith is decommissioned safely once every feature has moved. In practice you place a proxy in front, move one feature behind it, send its traffic to the new code, check the signals from Step 2 and repeat.
Two cautions from the sources. The same guidance warns that the proxy layer can become a single point of failure or a performance bottleneck. And Yoder's paper says the idea is independent of services, since you can evolve a system around the old one without adding services. Input: a monolith and a monitored proxy. Output: a monolith that shrinks one slice at a time.
Reading the whole path: quality starts from four golden signals, latency, traffic, errors and saturation. Measurement comes before fixes. Tests and review protect each change. The monolith shrinks one slice at a time behind a proxy.
Step-by-step description
- Pick the four golden signals and a target.
- Measure p99 and alert on user pain.
- Tests and small reviews guard each change.
- Move one feature at a time behind a proxy.
- Quality starts from four golden signals, latency, traffic, errors and saturation.
- Measurement comes before fixes.
- Tests and review protect each change.
- The monolith shrinks one slice at a time behind a proxy.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
The numbers below turn the sources into a triage reading. The 1,000 requests per second, the 1% tail and the 5 seconds come from Google's monitoring chapter; the rest is arithmetic.1 A 1% tail at 1,000 requests per second is 10 slow requests every second, which is 864,000 slow requests a day. If the slow 1% takes exactly 5 seconds (illustrative), the other 99% average about 50.5 milliseconds, so a healthy-looking average sits on top of a tail that real users feel.
An availability target works the same way. A 99.9% annual uptime target (illustrative) allows 8.76 hours of downtime a year and 43.2 minutes in a 30-day month (illustrative window).1 Each extra nine cuts the allowance tenfold: 432 minutes at 99%, 43.2 at 99.9% and 4.32 at 99.99% in 30 days.1
| Quantity | Value | Basis |
|---|---|---|
| Slow requests per second | 10 | 1% of 1,000 per second |
| Slow requests per day | 864,000 | 10 times 86,400 seconds |
| Mean of the other requests | about 50.5 milliseconds | illustrative: slow 1% takes 5 seconds |
| Downtime allowed per year at 99.9% (illustrative) | 8.76 hours | 0.1% of 8,760 hours |
| Downtime allowed per 30 days | 43.2 minutes | 0.1% of 43,200 minutes |
| Downtime allowed per 30 days at 99% (illustrative) | 432 minutes | 1% of 43,200 minutes |
| Downtime allowed per 30 days at 99.99% (illustrative) | 4.32 minutes | 0.01% of 43,200 minutes |
Text description of the diagram
- Each extra nine cuts the allowance tenfold: 432 minutes at 99%, 43.2 at 99.9% and 4.32 at 99.99% in 30 days.
- A 99.9% annual uptime target allows 43.2 minutes in a 30-day month.
Trade-offs and edge cases
The round is reported, not official. Candidates mostly describe it at senior and Staff level, so do not assume every LinkedIn loop has one. Formats vary: one report calls it a discussion of project metrics, CI/CD and reactive systems, another says it assesses how good you are at your craft. Prepare for engineering judgment, and confirm the format with your recruiter.
Craftsmanship also overlaps with behavioral questions such as "describe a situation where you showed operational excellence." LinkedIn has not defined where the line between the two lies, so treat the boundary as unofficial. Use the situation-task-action-result (STAR) method for experience questions, as in how to answer a teamwork question with the STAR method, and a reasoned order for hypotheticals; how to answer interview questions covers both shapes.
Shipping speed against quality is a recognized tension in review: the author of a change may be focused on delivering quickly, while the reviewer may care more about long-term quality. Agree the service-level objective (SLO) and what happens on a miss before the argument starts. Mentoring is reported as a topic too; with many junior engineers, small changes, review used as teaching and shared checklists are general practice, not a sourced rule. Interpersonal communication is the skill behind both.
How to answer it in an interview
You join a large team that owns a legacy application with weak tests, no monitoring and slow responses. What do you do as a Staff engineer?
First I make the system visible: latency, traffic, errors and saturation, reading p99 rather than averages, with alerts only on what users feel. I record every deploy so a regression maps to a change. Next I add tests around the riskiest paths and keep reviews small, because review does not replace testing. Then the measurements pick the bug and slowness work. Only after that do I extract features one at a time behind a proxy, the strangler fig approach, and I watch that the proxy does not become the bottleneck.
The spoken structure: say what you would measure, then how you protect change, then how the data picks the next work, then the incremental migration and its risk. For more shapes of answer, see common interview questions and how to answer them.
Common mistakes
- "Average latency is fine, so the service is healthy." (wrong) An average can hide a slow tail. (right) "I read p99 and error latency, because a good average can sit beside a slow 1% of requests."
- "Code review will catch the bugs." (wrong) LinkedIn's own post says review is not a substitute for testing. (right) "Review spreads knowledge; tests catch defects."
- "I would rewrite it as microservices in one go." (wrong) The pattern is incremental. (right) "I extract one feature at a time behind a proxy and decommission the monolith at the end."
- "The strangler fig needs microservices." (wrong) The idea is independent of services. (right) "It works for any gradual replacement; microservices are one target."
- "It is a coding round, so I will only drill algorithms." (wrong) Candidates describe a situational discussion; coding rounds are separate. (right) "I prepare stories and a reasoned order of work."
Follow-up questions
Rank the following in priority: bugs, no testing, no monitoring, slowness - what do you tackle first, and how do you eventually turn this into microservices?
No source sets a fixed ranking, so this is reasoning, not a sourced rule. Monitoring first, because you cannot prioritize what you cannot see; then a safety net of tests and rollback; then bugs and slowness in the order the data shows. For the move to microservices, use the strangler fig pattern: put a proxy in front, extract one feature at a time, watch the proxy as a possible bottleneck and decommission the monolith when all features have moved.
A teammate insists on shipping a feature on time even though it regresses p99 latency past your SLO. Who makes the final call?
No source in this page names a universal owner. A strong answer shows the regression in numbers, offers options such as a feature flag (a switch that turns the feature off), a rollback plan or a short fix, and uses the SLO and any error budget (the amount of failure the SLO allows before releases slow down) agreed beforehand; if the team still disagrees, the service owner or manager decides.
How do you keep quality high on a team with many junior engineers?
Keep changes small, treat review as teaching and make tests and monitoring part of the definition of done. This is general practice, so use a real example from your own work. A code-review strategy fits in one line: small changes, quick turnaround, and comments that teach. Mentorship principles are likewise general practice: set clear expectations, give specific feedback and let people own real work.
How do you describe a situation where you showed operational excellence?
Use the STAR shape. Situation and task: a service that paged too often or missed its latency target. Action: what you instrumented, which alerts you removed or tightened and what you changed in the team's process, such as a review step or a runbook. Result: a measured before and after from your own work, for example alert volume or p99 latency, never a figure you cannot back up.
How do you describe a situation where you suggested an improvement other engineers adopted?
Use the STAR shape again. Name the problem, the improvement you proposed and how you shared it. The result must show adoption by others, such as other teams reusing your tool or practice, plus a measured effect from your own data. An improvement only you used is a weaker story.
Does every LinkedIn interview loop have a craftsmanship round?
No source says so. Reports are mostly senior and Staff loops, so ask your recruiter, and prepare questions to ask the interviewer.
- LinkedIn has not published a description of the round, so treat every detail as reported by candidates.
- Define quality with latency, traffic, errors and saturation, plus an SLO.
- Make the system visible first, and read p99, not the average.
- Review spreads knowledge but does not replace testing, and small changes review best.
- Migrate with the strangler fig pattern, one slice at a time, and watch the proxy.
Sources
- Chapter 6 - Monitoring Distributed Systems (Site Reliability Engineering book) — Google (book published 2016; read 2026-10-26), 1 Jan 2016
- Scaling Collective Code Ownership with Code Reviews — LinkedIn Engineering Blog (Nikolai Avteniev; read 2026-10-26), 13 Jun 2018
- Strangler fig pattern — Amazon Web Services Prescriptive Guidance (undated; read 2026-10-26), 26 Oct 2026
- Strangler Patterns (PLoP 2020) — Hillside Group (Joseph W. Yoder; read 2026-10-26), 1 Jan 2020
- Interview Experience: LinkedIn, Staff Software Engineer (candidate report) — Substack (anecdote; read 2026-10-26), 1 Jan 2025
- LinkedIn software engineer interview (candidate comments) — Blind (anecdotal; read 2026-10-26), 21 Apr 2022
- LinkedIn Staff Software Engineer interview experience (candidate report) — EngineBogie (anecdotal, undated; read 2026-10-26), 26 Oct 2026
