Andreessen Horowitz Software Engineer Interview Guide

The 60-second brief

Andreessen Horowitz is a venture capital firm, and the Software Engineer role candidates describe sits on its technology side. The listed scope covers front-end engineering, backend systems, developer experience and IT infrastructure, in support of investment teams, portfolio companies and internal operations. The stack named for the role is React, JavaScript and TypeScript, with AWS, GCP, Docker, Kubernetes and internal developer tooling listed as nice-to-have experience. Reported scenarios include tracking incidents in real time, handling spikes in internal event volume and securing internal developer tools, so expect the role to mix web UI work with service and tooling work.

This guide is for engineers interviewing for a Software Engineer position at Andreessen Horowitz, whether the team leans front-end (React, TypeScript) or backend and tooling. It covers the two reported rounds, the reported technical, algorithm, behavioral and situational questions, how to build specific stories for the behavioral ones, and a seven-day plan that points at the technical questions by subject.

Candidates report two rounds over roughly 2-4 weeks: a Recruiter Screening Call, then Technical Recruiter Rounds that combine a data structures and algorithms session with a deep-dive technical discussion.

Focus areas

• Data Structures & Algorithms (DSA)
• Algorithmic Problem Solving
• JavaScript

Overview

The reported role description spans several kinds of engineering: web interfaces in React and TypeScript, backend services, developer workflows and infrastructure. That breadth shows in the reported questions. One group asks about your familiarity with React, JavaScript and TypeScript, modular front-end components, performance debugging and secure coding. Another asks you to design a backend service for high concurrency and data integrity. Preparing for only one side leaves a gap, so decide early which side your own experience covers and build a concrete example for the other.

The loop is short, two rounds reported over about 2-4 weeks, so each stage carries a lot. The recruiter call is reported to cover your past work, specific projects and stack familiarity. The technical stage is reported as a data structures and algorithms session plus a deep-dive discussion, with a walkthrough of a complex problem you have solved before. Reports do not say which individual question comes in which round, so prepare every reported question type rather than guessing.

Algorithm questions reported here are practical rather than exotic: an array problem with a target condition, recursive versus iterative complexity, how you test edge cases on array manipulation, which data structures suit a real-time incident tracker, and how you break one large function into testable utilities. In every one of them, state the brute-force version, name its cost, then show what removes the repeated work. Pair that with two or three polished project stories, because the same material feeds the deep-dive discussion and the behavioral and situational questions.

The Andreessen Horowitz interview process

The two rounds below are what candidates report, along with the question types each format naturally covers. Team and seniority may change the details.

Recruiter Screening Call

Candidates report a Recruiter Screening Call of about 40 minutes that covers your past work experience, specific projects and familiarity with the tech stack, which reports list as JavaScript, TypeScript and React. Behavioral questions of the situational and experience-based kind are also reported at this stage. Treat it as your first technical story, not a formality: be ready to describe two projects in terms of problem, your role, stack, decision and result, and to say honestly how deep your React, JavaScript and TypeScript experience goes.

What to demonstrate

• Past work experience and the specific projects you can describe
• Familiarity with the tech stack, named in reports as JavaScript, TypeScript and React
• Situational and experience-based answers, such as strengths and areas you are improving

How to prepare

• Write a two-minute walk through your career and a project sheet for two projects: context, your role, design, trade-off, result.
• Rate yourself honestly on React, JavaScript and TypeScript and prepare one example from your own work for each, such as typed props, hooks or an async bug.
• Rehearse the experience prompts out loud: a recent complex problem, your strengths, and an area you are working on.

Technical Recruiter Rounds

Candidates report Technical Recruiter Rounds as structured sessions on practical engineering skills, including a session split for data structures and algorithms and a deep-dive technical discussion. The coding part is reported as writing clean, optimized code while explaining your choices, and the discussion part as a walkthrough of a complex technical problem you have solved before. Prepare both modes: coding with spoken reasoning, and a project story you can take down several levels of detail.

What to demonstrate

• Working, readable code for an algorithm problem, with complexity stated
• Explaining implementation choices while you code
• A walkthrough of a complex technical problem from your own experience
• Practical engineering skills such as testing, refactoring and edge cases

How to prepare

• Practise array problems where you say the brute-force approach and its complexity first, then improve it with a hash map, two pointers, prefix sums or sorting.
• Write the time and space cost of a recursive solution, including call-stack space, then rewrite it iteratively with an explicit stack.
• Prepare one deep-dive project with a simple diagram, the alternatives you rejected, the measured outcome and what you would change.
• Practise building a short edge-case list (empty, single element, duplicates, negatives) and tracing your code through it before saying you are done.

Where candidates lose points

Jumping to an optimized array solution without stating the brute-force version

Say the brute-force approach and its complexity first. Then name the repeated work you are removing, whether with a hash map, two pointers, prefix sums or sorting, and give the new time and space cost.

Declaring the code finished without testing it against edge cases

Keep a standard list: empty input, a single element, duplicates, negative values, very large values and already-sorted input. Trace your code through two of them out loud, and mention any assumption about the input you are relying on.

Comparing recursion and iteration by time alone and ignoring the call stack

State the stack space of the recursive version, mention that deep recursion can overflow in JavaScript, and show the iterative version with an explicit stack or a memoized approach. Explain when each one is the right choice.

Answering the stack-familiarity question with a list of tools instead of examples

For React, JavaScript and TypeScript, give one specific thing you built or fixed for each, such as typed component props, a stale-closure bug or a re-render you removed. Be honest about the parts you have not used.

Telling the deep-dive or leadership story in 'we' language with no decisions of your own

Prepare a one-page sheet per project: context, your role, the decision you made, the options you rejected, the result and what you would change. Practise answering a follow-up question at each point.

Questions & practice

Given an array of integers, write an optimized solution to find a specific target condition and explain your t

Medium · Data Structures and Algorithms

Given an array of integers, write an optimized solution to find a specific target condition and explain your trade-offs against a brute-force approach.

Approach

1. Pin down the condition and the constraints before coding: array size, whether it is sorted, negatives, duplicates, whether to return indices or values, and whether one answer or all are needed. The usual instances are a pair summing to a target, or a subarray summing to k.
2. State the brute force and its cost: checking every pair (or every subarray using running sums) is O(n^2) time and O(1) extra space. It is fine for small n and useful later as a test oracle.
3. Optimise from the access pattern. For a pair sum, a hash map from value to index answers the question in one pass, O(n) time and O(n) space. On sorted input, two pointers need O(n) time and O(1) space, and sorting first costs O(n log n) and loses the original indices. For a subarray sum with negative numbers, use prefix sums with a hash map counting each prefix (O(n)); a sliding window works only when every value is non-negative.
4. Explain the trade-off out loud: the hash map spends memory to save time, sorting saves memory but changes the indices, and for tiny inputs the simple version can be the better engineering choice.
5. Cover the edge cases: empty or single-element arrays, duplicates such as [3,3] with target 6 (look up the complement before inserting the current value), no valid answer, and overflow in languages with fixed-width integers.

Follow-up

• The array contains negative numbers and you used a sliding window. What breaks, and what replaces it?
• Return every unique pair instead of one. How do you avoid duplicate pairs?
• The sorted array lives on disk and does not fit in memory. How does your approach change?

How do you evaluate the time and space complexity of a recursive algorithm versus an iterative approach?

Medium · Data Structures and Algorithms

Approach

1. Time for recursion is the number of calls multiplied by the work per call, which you get from a recurrence. With the Master theorem, merge sort's T(n) = 2T(n/2) + O(n) gives O(n log n). Naive Fibonacci, T(n) = T(n-1) + T(n-2) + O(1), grows exponentially (about 1.618^n, usually bounded as O(2^n)).
2. Space for recursion follows the maximum call depth, not the total number of calls. Naive Fibonacci uses O(n) stack despite exponential time. DFS on a balanced tree needs O(log n) stack but O(n) on a skewed one, and recursive binary search uses O(log n) where the iterative loop uses O(1).
3. An iterative version usually has the same time complexity. With an explicit stack it moves the memory from the call stack to the heap, which avoids stack overflow but not the memory cost.
4. Account for the runtime: Python's default recursion limit is 1000 and it has no tail-call optimisation, and most JavaScript engines (V8 included) do not perform proper tail calls, so deep recursion throws 'Maximum call stack size exceeded'.
5. Memoisation turns naive Fibonacci into O(n) time and O(n) space. Bottom-up iteration with two variables gives O(n) time and O(1) space. Choose recursion when the problem is naturally recursive and shallow, such as trees or divide and conquer, and iteration when the depth can grow with the input.

Follow-up

• What are the time and space complexity of recursive versus iterative binary search?
• Convert a recursive in-order traversal to an iterative one. What does your explicit stack hold at each step?
• When does memoisation fail to improve a recursive solution?

Can you walk through your process for testing edge cases in an array manipulation problem?

Medium · Data Structures and Algorithms

Approach

1. List the edge-case categories before writing code: empty array, one element, two elements, all values equal, duplicates, already sorted and reverse sorted, negatives and zero, extreme values (overflow), the answer at the first or last index, no valid answer, and very large n.
2. Check loop boundaries explicitly: off-by-one at index 0 and n-1, half-open versus closed intervals, a window size equal to or larger than n, and k = 0.
3. Settle mutation semantics: does the function modify in place or return a new array, does the caller expect the input untouched, and is anything modifying the array while iterating over it?
4. Then test in order: hand-trace one small ordinary example, then each edge case, then a randomised comparison against a brute-force oracle (property-based tools such as fast-check for JavaScript or Hypothesis for Python).
5. State the invariant each loop maintains (for example, 'everything left of i is already partitioned') and confirm it holds at the start, at each step and at exit.

Follow-up

• Which of these cases is most likely to break a two-pointer solution?
• How would you write a randomised test that compares your solution with a brute-force version?
• Your function passes every test you wrote but fails in production on one input. How do you find that input?

What data structures would you select for a real-time incident response tracking system and why?

Medium · Data Structures and Algorithms

Approach

1. Start from the operations: create an incident, update its status and severity, assign a responder, list open incidents by priority, escalate anything left unacknowledged past a deadline, keep a timeline, and deduplicate repeated alerts.
2. Use a hash map from incident id to record for O(1) lookup and update, plus secondary indexes (hash map from status or responder to a set of ids) for the common filtered views.
3. Use a priority queue (binary min-heap) keyed on (severity, created time) to pick the next incident, at O(log n) per push and pop. A plain heap cannot efficiently update or remove an arbitrary entry, so either keep an index map (an indexed heap) or use lazy deletion that skips stale entries when they are popped.
4. Run escalation timers from a min-heap ordered by deadline, or a timing wheel when there are many timers. An acknowledgement cancels lazily: when a timer fires, check the incident's current state first.
5. Keep each incident's timeline as an append-only event list and deduplicate alerts with a set of fingerprints that expire after a TTL. Then name the trade-off: in-memory structures are fast but are lost on restart, so with several responders or processes the state moves to a shared store (for example Redis hashes and sorted sets) with version checks on updates.

Follow-up

• How do you change an incident's severity without scanning the whole heap?
• Ten thousand alerts arrive from one root cause within a minute. How do you collapse them?
• What state survives if the tracking process restarts, and how do you rebuild the rest?

How do you refactor monolithic algorithmic logic into clean, testable utility functions?

Medium · Data Structures and Algorithms

Approach

1. Pin the current behaviour before changing anything: write characterisation tests with recorded inputs and outputs, including the edge cases, so every later step can be checked.
2. Find the seams. Separate pure computation from side effects (input parsing, database calls, logging, the clock, random numbers), and pass those effects in as parameters or dependencies so the core logic is deterministic.
3. Extract in small steps, such as validation, the core algorithm and output formatting, each as a small pure function named for what it returns, with no shared mutable state. Keep the original signature as a thin wrapper so callers do not change.
4. Run the tests after every extraction and commit each step separately. Use the IDE's extract-function refactoring to reduce manual mistakes.
5. Avoid over-fragmenting: extract pieces that have their own invariants and tests, and measure afterwards if the split adds extra passes over the data or extra allocations on a hot path.

Follow-up

• The function reads the current time and calls a database. How do you unit test it?
• How do you gain confidence that the refactor did not change behaviour on inputs you never thought of?
• When would you deliberately leave a long function as it is?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

• The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
• How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

What is your familiarity with our core tech stack, specifically regarding React, JavaScript, TypeScript, and U

Medium · Technical and Domain Questions

What is your familiarity with our core tech stack, specifically regarding React, JavaScript, TypeScript, and UI development?

Approach

1. Answer with evidence rather than a self-rating: name one React feature you shipped, what you owned in it, and the patterns it used (function components, hooks, data fetching, forms).
2. Show the JavaScript underneath React: closures (a stale value inside useEffect or useCallback when the dependency array is incomplete), the event loop (promise microtasks run before the next macrotask), and reference equality, which decides whether props count as changed.
3. For TypeScript, describe strict mode and modelling component state as a discriminated union ({status:'loading'} | {status:'error', error} | {status:'success', data}) so impossible states fail to compile. Use unknown instead of any at API boundaries, with runtime validation, because types are erased at runtime.
4. For UI work, explain the render model: a state change re-renders the component and its subtree, so React.memo and useMemo help only when props are referentially stable. List keys must be stable ids, not array indexes, when items can be inserted or reordered.
5. Name a real gap honestly and say how you are closing it, instead of claiming equal depth in all four areas.

Follow-up

• Why can an array index used as a key show the wrong row state after an insert at the top of a list?
• When would you move from useState plus context to useReducer or an external store?
• How would you type a component that accepts either href or onClick, but never both?

How do you approach building modular, maintainable front-end components that adhere to strict naming conventio

Medium · Technical and Domain Questions

How do you approach building modular, maintainable front-end components that adhere to strict naming conventions and coding standards?

Approach

1. Split components by responsibility. Presentational components take props and render. Data fetching and stateful logic move into custom hooks, which must start with use for the Rules of Hooks lint rule to check them, and which can be tested without rendering markup.
2. State the naming rules and say how they are enforced: PascalCase components with one component per file named after it, onX for callback props and handleX for local handlers, isX or hasX for booleans. ESLint (react-hooks plugin, typescript-eslint naming-convention) and Prettier run in pre-commit and CI, so style never becomes a review argument.
3. Keep the typed props API small and prefer composition (children, slots, compound components) to a growing list of boolean flags. Keep styles, tests and stories next to each component.
4. Test through behaviour with React Testing Library, querying by role and label. This also pushes the markup toward accessibility. Use Storybook or visual snapshots for components with many visual states.
5. Trade-off: extract shared components after real duplication (the rule of three), not in advance. A premature abstraction costs more to undo than a copy does.

Follow-up

• A shared Button has picked up fifteen boolean props. How would you refactor it without breaking existing callers?
• How would you introduce a new lint rule to a large codebase that already violates it in hundreds of places?
• Two sibling components need the same state. Where does it live, and what does that choice cost?

Can you explain how you would design a scalable backend service to handle high concurrency and data integrity?

Medium · Technical and Domain Questions

Approach

1. Fix the scope first: the read/write ratio, peak concurrency, and what integrity means here (no lost updates, no double charge, uniqueness, referential integrity). Each of those calls for a different mechanism.
2. Keep the app tier stateless behind a load balancer so it scales horizontally. Put a connection pooler (for example PgBouncer) in front of the database, because database connections usually run out before CPU does.
3. Put integrity in the database: transactions, unique and foreign-key constraints, and atomic conditional updates (UPDATE accounts SET balance = balance - :x WHERE id = :id AND balance >= :x, then check the affected row count). For contended read-modify-write, choose optimistic concurrency (a version column, retry when 0 rows match) or SELECT ... FOR UPDATE on hot rows.
4. Make writes safe to retry: the client sends an idempotency key, stored under a unique constraint, so a retried request returns the first result instead of applying twice. Use a transactional outbox so events are published only for committed state.
5. Scale reads with replicas and caches, and name their cost: replication lag breaks read-your-writes, and a cache needs invalidation or a short TTL. Scale writes by partitioning on a key and pushing slow work onto a queue with backpressure; cross-partition transactions then become expensive.

Follow-up

• Two requests decrement the same inventory row at the same moment. Walk through what happens under your design.
• How do you stop a cache from serving a value older than a write that just committed?
• An instance dies halfway through a request. What state can the client and the database be left in?

How do you ensure secure coding practices when building internal developer tools or customer-facing applicatio

Medium · Technical and Domain Questions

How do you ensure secure coding practices when building internal developer tools or customer-facing applications?

Approach

1. Start with a threat model: who uses the tool, what data and permissions it touches, and where the trust boundaries are. Internal developer tools still face insiders, stolen laptops and SSRF from inside the network.
2. Map concrete controls to common vulnerability classes. Use bind parameters, never string concatenation, against injection. Rely on output encoding, avoid dangerouslySetInnerHTML (or sanitise with DOMPurify) and set a Content Security Policy against XSS. Use SameSite cookies or CSRF tokens. Check authorization on the server for every object a request touches, to prevent IDOR.
3. Secrets: keep them out of the repository and the client bundle, load them from a secret manager, and use least-privilege, short-lived credentials. Put session tokens in HttpOnly, Secure cookies.
4. Supply chain: commit lockfiles, run dependency scanning (npm audit, Dependabot or similar) and static analysis in CI, and review new dependencies before adding them.
5. For internal tools specifically: SSO with role checks, audit logs of who did what, allowlists for outbound hosts and command arguments, and validation of input even from trusted users.

Follow-up

• Where would you store an auth token in a browser app, and what attack does each option expose you to?
• An internal tool builds shell commands from user input. How do you make it safe?
• You find a live API key in the git history. What do you do, and in what order?

What were the primary trade-offs in your chosen architecture for your most recent project, and what did you le

Medium · Behavioral and Experience Discussions

What were the primary trade-offs in your chosen architecture for your most recent project, and what did you learn from the outcome?

Approach

1. Structure the answer as: constraints (scale, team size, deadline), the options you seriously considered, the choice, the cost you knowingly accepted, the measured outcome, and what you would change.
2. Name the real trade-off axes rather than general virtues. Examples: a monolith versus services (independent deploys versus operational overhead), relational versus NoSQL (joins and transactions versus horizontal write scaling), synchronous calls versus a queue (simplicity and latency versus resilience and backpressure), and caching (latency versus staleness).
3. Quantify the outcome with before-and-after numbers you can defend: p95 latency, cost, deploy frequency, incident count or delivery time.
4. For the lesson, give one decision that turned out expensive, the signal that revealed it, and what you would decide now. Separate a bad outcome caused by bad luck from one caused by a bad decision.
5. Be ready to sketch the architecture on request: components, data flow, where state lives, and the failure path.

Follow-up

• If load grew ten times, which component would fail first, and how would you know?
• Which rejected option came closest, and what would have made you choose it?
• What would you build differently with half the time, or with twice the team?

What steps do you take when onboarding onto a new, unfamiliar codebase with limited documentation?

Medium · Situational and Problem-Solving Scenario

Approach

1. Get the project building and running locally and run its test suite first. The build files, CI configuration and dependency manifest show the entry points, services and external dependencies faster than reading code at random.
2. Trace one real user flow end to end with a debugger or added logging, from the route or entry point through the service layer to storage, and sketch it as you go.
3. Read the data model or database schema early, and use git log and git blame on frequently changed files to learn why the code looks as it does and who to ask.
4. Ship a small, low-risk change early, such as a bug fix or a missing test, to learn the review, deploy and monitoring path.
5. Write down what you learn (setup steps, a component map, gotchas) and add it to the repository, and ask specific questions after trying, not before.

Follow-up

• How do you decide what is safe to change in code that has no tests?
• How would you find the code behind one particular button in the UI?
• What would you write down first for the next engineer who joins?

How do you prioritize your engineering backlog when faced with competing stakeholder demands?

Medium · Situational and Problem-Solving Scenario

Approach

1. Put every request into one visible, ranked backlog, and for each item record the goal, the requester, any hard deadline and the cost of delay.
2. Rank with an explicit method so the order can be explained: impact against effort, RICE ((reach x impact x confidence) / effort) or WSJF (cost of delay / job size). Keep security fixes and incidents in a separate lane above feature work.
3. Reserve a fixed share of capacity for technical debt and interrupts, so planned work does not quietly slip every sprint.
4. When stakeholders conflict, take the trade-off, written out, to the person who owns the shared goal instead of choosing silently. When you say no, offer an alternative: smaller scope, a later date or a workaround.
5. Review the order on a regular cadence and tell requesters what moved and why.

Follow-up

• Two senior stakeholders both insist their item is first. What do you do?
• How do you make room for refactoring when every request is a feature?
• Describe an item you deprioritised and how you told the person who asked for it.

What is your process for evaluating a third-party library or tool before integrating it into your stack?

Medium · Situational and Problem-Solving Scenario

Approach

1. Define the need first and compare it with building it yourself or using something already in the stack. A small, well-understood function often does not justify a new dependency.
2. Check fit with a short spike on your own workload: API ergonomics, quality of the TypeScript types, and, for front-end code, bundle size and tree-shaking.
3. Check project health and legal fit: release cadence, responsiveness to issues, number of active maintainers, adoption, and licence compatibility (permissive MIT or Apache-2.0 versus copyleft GPL or AGPL obligations).
4. Check security: known advisories (npm audit or similar), the number of transitive dependencies, install scripts, and what access the library needs at runtime.
5. Limit the integration risk: wrap the library behind your own small interface so it can be replaced, pin the version with a lockfile, and write down the exit plan before adopting it.

Follow-up

• A library you depend on stops being maintained. What do you do?
• How do you weigh a large dependency against writing two hundred lines yourself?
• How would you catch a malicious release of a transitive dependency?

What strategies do you use for debugging and optimizing performance in modern web applications?

Medium · Technical and Domain Questions

Approach

1. Measure before changing anything. Use field data (Core Web Vitals: LCP, INP, CLS) to see what real users experience, and lab tools (Lighthouse, the Chrome DevTools Performance panel with CPU and network throttling) to reproduce it.
2. Network side: read the waterfall for oversized bundles, render-blocking scripts and CSS, and chained requests. Fixes include code splitting with dynamic import() and React.lazy, compression, cache headers and a CDN, correctly sized images in modern formats, and preloading the LCP resource.
3. Main-thread side: find long tasks (over 50 ms) in the performance profile and use the React Profiler to spot unnecessary re-renders. Fixes include stabilising props before memoising, virtualising long lists, debouncing expensive input handlers, and moving heavy computation into a Web Worker.
4. Memory leaks: compare heap snapshots before and after repeating an action, and look for detached DOM nodes, plus listeners, intervals or subscriptions that a useEffect cleanup never removes.
5. Change one thing at a time and measure again. Then lock in the gain with a performance budget, such as a bundle-size check in CI.

Follow-up

• The page is slow for only some users. How do you find out which users, and why?
• When does adding useMemo make performance worse?
• How do you tell whether a slow LCP comes from the server response or from client-side rendering?

How would you approach troubleshooting a critical production outage under tight time constraints?

Medium · Situational and Problem-Solving Scenario

Approach

1. Mitigate before you diagnose. Declare the incident, split the roles (one person coordinates, one communicates, the rest investigate), and size the impact from dashboards: error rate, latency, traffic and saturation.
2. Ask what changed: recent deploys, configuration or feature-flag changes, infrastructure events, traffic spikes, and the status of each dependency. If a change lines up with the start of the impact, roll it back or turn off the flag first and investigate afterwards.
3. Narrow the fault by comparing healthy and unhealthy slices (region, host, version, endpoint, customer), then follow the failing request through logs and traces to the first component that errors.
4. Send stakeholders updates on a fixed cadence and keep a timestamped log of every action taken, because the review afterwards depends on it.
5. Confirm recovery from the metrics, not from the absence of complaints. Then run a blameless postmortem covering root cause, contributing factors and owned action items (alerts, tests, runbooks, safer rollout).

Follow-up

• The rollback did not fix it. What do you do next?
• How do you choose between a quick hotfix now and waiting for a full fix?
• Which alert or check would have caught this before users noticed?

Suggested practice checklist

Each day targets one reported area, from the recruiter call through array problems, front-end topics, backend design and behavioral stories, and ends with a deliverable you can review. If your loop is weeks away, repeat days 2 to 4 with new problems.

Day 1 — Map the loop and write your project sheets

• Write the two reported rounds, the Recruiter Screening Call and the Technical Recruiter Rounds, with what each is reported to cover.
• Write a two-minute spoken walkthrough of your career and read it aloud once.
• Rate yourself on React, JavaScript and TypeScript and write one example from your own work for each, marking the gaps.
• Build a one-page sheet for two projects: context, your role, design, trade-off, result.

Deliverable: A two-minute career script, a stack self-rating with an example per technology, and two project sheets.

Day 2 — Array problems from brute force to optimal

• Solve four array problems that search for a target condition: pair sum with a hash map, pair sum on sorted input with two pointers, subarray sum with prefix sums, and a sliding window.
• Before coding each, say the brute-force approach and its complexity, then the optimized time and space.
• After each, write an edge-case list (empty, one element, duplicates, negatives, large values) and trace the code through two entries.

Deliverable: Four working solutions, each with its stated brute-force and optimized complexity and a written edge-case list.

Day 3 — Complexity, data structures and refactoring

• Take a recursive solution such as a tree traversal or a memoized recursion and write its time and space cost, including the call stack. Rewrite it iteratively with an explicit stack.
• Design the data structures for a real-time incident tracker: a map by incident id, a heap ordered by severity and a time-ordered structure for recent events. List each operation with its cost.
• Refactor one long function into small, named, pure helper functions and add a unit test for each.

Deliverable: A recursive and an iterative version with a complexity table, an operations table for the incident tracker, and a refactored function with tests.

Day 4 — React, JavaScript and TypeScript depth

• Build a small filterable table as a set of typed components with consistent naming, separate presentational and data-fetching parts, and a test for each.
• Profile it with the browser performance panel and the React profiler, remove one unnecessary re-render, and write down the before and after.
• Write a secure-coding checklist for front-end and internal tools: output escaping, risks of raw HTML injection, token storage, server-side input validation and a dependency audit.

Deliverable: A typed component set with tests, a before-and-after profiling note and a one-page secure-coding checklist.

Day 5 — Backend design and production judgment

• Design a backend service for high concurrency and data integrity. Write the API, the data model, an idempotency key for retries, a unique constraint or transaction for integrity, a queue and a cache, and say what breaks at ten times the traffic.
• Write a triage sequence for a production outage: what changed recently, which signals to check, how to mitigate or roll back first, and how to find the root cause afterwards.
• Write a checklist for entering an unfamiliar codebase with little documentation: run the tests, trace one request end to end, read recent history and write down open questions.

Deliverable: A one-page service design with failure handling, an outage triage script and a codebase-onboarding checklist.

Day 6 — The deep-dive and project stories

• Rehearse your strongest project aloud with a simple diagram: context, constraints, the options you rejected, the result and what you would change. Record it and cut anything that rambles.
• Write the architecture trade-off answer for your latest project, naming at least two alternatives and what each would have cost.
• Outline the story of a project you led from inception to deployment, including scope cuts, risks, rollout and what slipped.

Deliverable: A recorded deep-dive walkthrough, a written trade-off answer and a project-lead story outline.

Day 7 — Behavioral and judgment answers, then a mock

• Write structured outlines for three stories: a cross-functional conflict, a mid-sprint requirement change, and your strengths and improvement area.
• Write short decision checklists for prioritizing a backlog across competing stakeholders and for evaluating a third-party library (maintenance, license, security record, size, API fit, cost of removing it).
• Run a mock: one array problem aloud with edge cases, then your deep-dive project, and record both.

Deliverable: Three story outlines, two decision checklists and one recorded mock session.

Stories for the experience and situational questions

Reported behavioral and situational questions cover a recent complex problem, architecture trade-offs, team conflict, leading a project, strengths and weaknesses, and changing requirements. For a Software Engineer role, build four or five stories from your own work that each show a decision you made, the trade-off, the measured result and what you learned. Then reuse them across prompts.

1. What were the primary trade-offs in your chosen architecture for your most recent project, and what did you learn from the outcome?

Can you describe in detail a recent complex technical problem you worked on, including the context and solutio

Medium · Behavioral and Experience Discussions

Can you describe in detail a recent complex technical problem you worked on, including the context and solution design?

Approach

1. Choose a problem you owned whose design you can sketch in a minute. Reports describe a deep-dive discussion of a complex problem you solved, so the story has to hold up when someone asks why at each step.
2. Give the context in two sentences: the system, the constraint and why the obvious fix did not work. Spend most of the time on the solution design: components, data flow, the options you weighed and the reason you picked one.
3. Say what you personally did versus what the team did. Replace a vague 'we built it' with the specific decision, code or investigation that was yours.
4. Close with a result you actually measured (latency, error rate, deploy time, tickets) and one thing you would change now. A story with no outcome or no reflection sounds unfinished.

Follow-up

• Why did you not take the other option you considered?
• What would break first if the load or the data grew ten times?
• If you rebuilt it today, what would you do differently?

How do you handle disagreements or conflicts within a cross-functional engineering team?

Medium · Behavioral and Experience Discussions

Approach

1. Pick a real disagreement about a concrete technical or scope decision with a product manager, designer or another engineer, not a personality clash. Name what the other function was trying to protect, such as a deadline, a user experience or a maintenance cost.
2. Show how you moved it from opinion to evidence: a prototype, a benchmark, an error count or a written comparison of options with their costs. Describe how you agreed on the deciding rule before looking at the numbers.
3. State the outcome plainly, including when the decision went against you. Disagreeing and then committing to the decision, and helping it succeed, is a strong ending.
4. Finish with the working relationship afterward. A story where you were right and the other person was unreasonable shows little about how you work with people.

Follow-up

• What would you have done if the evidence had not settled it?
• How did the other person feel about the result, and how do you know?
• Has a similar disagreement come up again, and what did you change?

Can you share an example of a time you successfully led a project from inception to deployment?

Medium · Behavioral and Experience Discussions

Approach

1. Choose a project where you made the scope and sequencing decisions, from the first problem statement through production release. Open with what the project was for and who depended on it.
2. Walk through the stages: how you cut the scope, the milestones, the dependencies on other teams, the top two or three risks and what you did about each one early.
3. Cover the release itself: tests, a feature flag or staged rollout, monitoring after launch and the rollback plan. This is the 'deployment' half of the question and is often skipped.
4. Include something that slipped or went wrong and how you re-planned. Finish with a measured result and a lesson. Listing tasks without any decisions sounds like participation, not leadership.

Follow-up

• What was the riskiest assumption at the start, and how did you test it?
• How did you split the work among the people on the project?
• What would you cut if the deadline had been moved up by a week?

What are your primary professional strengths, and what specific areas are you actively working to improve?

Medium · Behavioral and Experience Discussions

Approach

1. Name two strengths that matter for this role, such as debugging production problems, designing maintainable React components or writing tests, and attach one short piece of evidence to each. A claim without an example is easy to forget.
2. Pick a genuine area to improve, not a strength in disguise like working too hard. Choose something you can explain, such as delegating, writing a design note before coding or going deeper on TypeScript typing.
3. Say the concrete mechanism you are using to improve (a habit, a reviewer, a course, a practice project) and one sign that it is working.
4. Keep the whole answer short and balanced, and tie it back to the work. A long defensive explanation of the weakness undoes the honesty.

Follow-up

• When did that weakness last cost you something on a project?
• How would a former teammate describe your strengths and your growth area?
• What are you working on right now to improve it?

How do you handle requirements that change mid-sprint during an active development cycle?

Medium · Situational and Problem-Solving Scenario

Approach

1. Tell a story with a real change: what changed, who raised it, when you learned of it and how much work was already done or in progress.
2. Show how you assessed the impact before reacting: what could be kept, what must be redone, what the change costs in time and risk, and whether it can be isolated behind an interface or a feature flag.
3. Describe the conversation with the stakeholder as a set of options, such as swap scope, move a date or split the work, and how the team agreed on what left the sprint. Silently absorbing the change and flatly refusing it are the two common mistakes.
4. Close with what you changed afterward, such as confirming requirements earlier, shorter feedback loops or smaller increments, and how the tickets and tests were updated.

Follow-up

• What if the request came from a senior stakeholder and nothing could be dropped?
• What happened to the code you had already written?
• How do you reduce the chance of mid-sprint surprises on the next project?