Skip to content
sitraka.lu

Tools / Free tool

Technical interview prep: coding, system design, leadership

Interviews at Google and at most large tech companies combine coding rounds (data structures, algorithms, complexity), one or more system design rounds for experienced engineers, and a behavioural round on leadership and collaboration. This page is a practice bench for the three, built from public material; it claims no inside knowledge of any employer's process. Read the employer's own pages first (links at the bottom), then train here.

How a coding round usually runs

  1. 01Restate the problem and ask clarifying questions: input sizes, edge cases, what to return when nothing matches.
  2. 02Work through one or two small examples by hand before writing code.
  3. 03State a brute-force approach and its complexity, then look for the better one; say what you are thinking, silence is the enemy.
  4. 04Write clean code in one language you know deeply; name things well, keep functions short.
  5. 05Test it out loud with a normal case, an edge case and a large input; fix what you find.
  6. 06Give the final time and space complexity, and mention what you would improve with more time.

System design: a method you can repeat under pressure

A design round usually lasts 45 to 60 minutes with a deliberately vague prompt. The interviewer wants to see how you turn ambiguity into a defensible architecture. Follow the same seven steps every time; the drill below makes you write them out.

  1. 01

    Clarify requirements

    Who are the users and what must the system do? Which features are out of scope? Non-functional needs: latency, availability, consistency, durability, privacy?

  2. 02

    Estimate the scale

    Daily active users, requests per second at peak, read/write ratio, data written per day, retention, storage after five years, bandwidth. Round aggressively, show the arithmetic.

  3. 03

    Define the API

    Main endpoints or RPCs with inputs and outputs. Authentication, pagination, idempotency keys for writes, rate limits.

  4. 04

    Data model and storage

    Entities and relations, hot fields, indexes. SQL or NoSQL and why. Partition key. What must be strongly consistent and what can lag?

  5. 05

    High-level architecture

    Clients, load balancer, stateless services, cache, database, queue, CDN, object storage. Draw the request path for the two most important flows.

  6. 06

    Deep dive on the hard part

    Pick the bottleneck: hot keys, fan-out, large joins, a single writer. Show two options and choose one with numbers.

  7. 07

    Trade-offs, failures and operations

    What breaks first when traffic doubles? Replication and failover, backups, degraded modes, monitoring and SLOs, cost. Recap the design in one minute.

Study tracker: data structures and algorithms

0/12 confident

Tap a topic to cycle its status: not started, practising, confident. Aim for confident on all twelve before the loop.

Building blocks to know cold

0/12 confident

Same three states. You should be able to explain each block in two minutes, with its failure modes.

Design drill

Pick a prompt, set a 45-minute timer, and write the seven steps as you would say them aloud. Then grade yourself with the rubric. Everything is saved in this browser; nothing is sent anywhere.

45:00

Self-review

0/6 criteria met

The leadership and collaboration round

Expect questions on how you handle ambiguity, disagreement, mistakes and mentoring. Prepare five STAR stories (situation, task, action, result) with real numbers, one of them a failure you owned. Interviewers look for judgement, ownership and how you make the people around you better, not for heroics.

Primary sources to read first

This page is editorial guidance built from public material, not a leak of anyone's interview bank. Employers change their processes; their own pages win over anything written here.

Track your applications in Work & Career →