ArchDays · October 29, 2021
The design section in interviews
Checking a candidate's system design skills
/ The Design Section in Tech Interviews · ArchDays 2021
Slide contents
1. The design section in interviews
Checking a candidate's system design skills
2. From the hiring funnel to how to learn this
What we'll cover
The hiring process and why we run a design section
What the candidate gets out of it
How the section and a typical task look
How we score candidates, and how to learn this
3. 01. What the hiring process looks like
Using a backend developer as the example
4. The design section is the technical interview's third section
And it is not needed at every level
A screening interview with a recruiter
Technical interviews: algorithms, language, design
A team interview and the offer
Junior and Middle go without the design section
5. 02. Why we check this at all
From the company's side and the candidate's
6. Decisions are decentralised — teams design for themselves
Why we check system design skills
16M+ customers, growing about 35% a year
A multi-product company with its own IT verticals
The products merge into an ecosystem
Headcount grows and architecture decisions decentralise
7. Every outcome of the section gives the candidate something
What the candidate gets out of it
Aced it — we can offer more interesting terms
…both in pay and in the work itself
Did fine — a team where they can grow
Did not pass — personalised feedback
8. 03. What the design section looks like
Seven steps and a typical task
9. The section unfolds step by step
From the problem statement to the follow-up questions
10. The diagram gets worked through in three passes
Data flows and system components
First the happy path
Then load and non-functional requirements
Then corner cases — when parts of the system fail
The output is the conceptual diagram
11. We draw in Sketchboard.me, in Software Sketching mode
What a typical task looks like
The problem statement
Functional and non-functional requirements
Load parameters
System boundaries, scenarios and the public API
12. 04. How we score the candidate
Eight axes and the level read off them
13. Eight axes, not one verdict
The scoring criteria
Framing the problem, boundaries and the API
Data flows, conceptual and real diagrams
Load and sizing questions
How readable the diagram is, plus follow-ups
14. 05. Wrap-up
And how to learn to design systems
15. The questions we covered
What is left is learning to design systems well
What the hiring process looks like
Why we check system design skills
What the candidate gets out of it
What the section and a typical task look like
How we score candidates
16. Links for further study
The sources from the talk's closing slide
The article «How to get better at software design — books»
The «System Design Primer» resource
The «Distributed Systems» and «Essential Architecture» courses
The ArchDays, Highload and Hydra conferences
17. Thank you!
polomodov.tech
All slides and links are in the Telegram channel
Alexander Polomodov, Technical Director & Fellow, T-Technologies
@book_cube