Abodewell Software Engineer Interview Guide

The 60-second brief

Candidate reports for Abodewell do not name a specific product, so this guide stays with how the role is described. Engineers are said to sit between algorithm-heavy work and applications that users touch, including full-stack React development, and to work with product leads, designers and data scientists. Day to day, the reports mention turning product requirements into technical specifications, building features across the stack and writing code that teammates can read and extend. A sensible way to prepare is to practise writing efficient code you can justify and to practise explaining how front-end and back-end pieces fit together.

This guide is for candidates interviewing for a Software Engineer position at Abodewell. It covers the three reported stages (Online Coding Challenge, Technical Phone Screens, On-site Experience), the coding, system design and behavioral questions candidates report, and the web fundamentals those questions rely on: REST, WebSockets, long polling, sessions and cookies. It also covers React, which candidates mention as a nice-to-have and as a framework you may be asked to pick up quickly. It does not describe team-specific work, because the reports do not.

Reports describe three stages spread across about 3-5 weeks: an Online Coding Challenge, then Technical Phone Screens covering algorithm efficiency and architecture knowledge, then a multi-day On-site Experience with a practical project.

Focus areas

• Time Complexity Analysis
• React
• Algorithms

Overview

The role as candidates describe it mixes two kinds of work. One is algorithmic: choosing data structures, reasoning about time and space, and replacing a slow solution with a faster one. The other is web engineering: REST and HTTP, real-time transport, sessions and cookies, and keeping a full-stack application maintainable as features pile up. Requirements people mention are proficiency in at least one major language, solid data-structure fundamentals and a working grasp of web architecture. React, other front-end frameworks, full-stack exposure and cloud basics are listed as nice-to-have.

The reported topics map directly onto preparation. On the algorithm side, expect the questions in this guide: take a quadratic solution to linear, rearrange an array using minimal extra space, handle a Knapsack variation, compare data structures for a search task, and explain what you do when a first version fails on large inputs. On the design side, expect to sketch a data flow between components, choose between WebSockets and long polling, and justify how you handle REST traffic and session state. Reports mention implementing core algorithms without leaning on library helpers, so practise writing the hash map counting, the sort, the binary search and the DP table yourself.

Process details candidates mention shape how to practise. A take-home challenge is mentioned in which a new framework such as React may be required, with working but not fully hardened code acceptable as long as the core requirements are met. Candidates are advised to say their reasoning aloud when stuck on a phone screen, to explain technical choices to non-engineers, and to test their own submissions against self-made edge cases. Candidates also report responses within about a week per stage and that telling the recruiter or CEO about competing timelines is welcome. Use the plan to cover both tracks and to rehearse thinking aloud, since much of the loop is spoken.

The Abodewell interview process

Candidates describe three stages in this order. The descriptions below say what is reported for each stage and how to prepare for it.

Online Coding Challenge

Candidates report that the process opens with an Online Coding Challenge meant to check technical skills. The reports give no format details beyond that, so prepare for working code under whatever constraints the platform sets. The coding questions in this guide (quadratic to linear, in-place array work, a Knapsack variation, data-structure trade-offs) are the practice material for a stage like this. Candidates are advised to write their own edge cases before submitting, and a take-home submission is described as needing to function and cover the core requirements, with the edge cases used as the basis for follow-up questions. Treat submission as the end of testing, not the start: run empty, single-element, duplicate-heavy and maximum-size inputs first.

What to demonstrate

• Working code that meets the stated requirements
• Prep focus: efficiency, code quality and edge-case handling, which reports tie to the take-home challenge

How to prepare

• Rewrite three classic quadratic solutions (pair sum, duplicate detection, longest subarray with a target sum) using a hash map, two pointers or prefix sums, and state the before and after complexity.
• Implement 0/1 Knapsack as a 2D table, then as a one-dimensional array iterated backwards, so a variation does not catch you out.
• Write a short checklist of edge inputs and a brute-force checker you run against random small cases before submitting anything.

Technical Phone Screens

Reports describe the phone screens as centered on how efficient your algorithms are and how well you know web architecture. Reported topics include moving from a brute-force answer to an optimized one, how input growth by a factor of 100 changes efficiency, REST, WebSockets versus long polling, and session and cookie handling. Because a phone screen is spoken, the advice candidates share is to narrate your thinking and keep talking if you get stuck instead of going silent. Structure each answer the same way: state the naive approach and its cost, name the bottleneck, change the data structure, then give the new complexity and one edge case.

What to demonstrate

• Reasoning about algorithmic efficiency out loud
• Architectural knowledge of web protocols and state handling
• Ability to recover and keep communicating when stuck

How to prepare

• Practise answering How would you optimize this algorithm from O(n^2) to O(n)? aloud with a fixed structure: baseline, bottleneck, new structure, new complexity, edge case.
• Prepare a two-sentence contrast of WebSockets and long polling with one scenario each, such as a real-time messaging feature, and the failure mode of each.
• Write out how a session cookie is issued, stored and invalidated, including the HttpOnly, Secure and SameSite attributes, so you can speak to it without notes.

On-site Experience

Reports describe a multi-day on-site with a practical project. The reports give no further detail on the project, so a sensible way to prepare is to build something small end to end beforehand. Candidates also say the CEO and technical leadership are often involved in hiring in general, and one tip is to treat every conversation, even a coffee chat, as a chance to ask thoughtful questions, so have some ready. Useful topics to rehearse are how a full-stack application stays maintainable as features grow and how you would diagram data flow between front end and back end. Candidates are also advised, as general guidance, to practise explaining technical choices to non-engineers.

What to demonstrate

• A multi-day on-site format that includes a practical project
• Delivering a working practical project

How to prepare

• Build a small full-stack feature in one sitting (a React front end calling a REST endpoint with a form, a list and error handling) and write a short README of the trade-offs you made.
• Practise sketching a data flow diagram for a real-time messaging feature, labeling each hop with its protocol and where state lives.
• Prepare a plain-language explanation of one technical decision you made, aimed at a designer or product lead, and a handful of questions for senior people you may meet.

Where candidates lose points

Presenting the optimized answer without the O(n^2) baseline

For the quadratic-to-linear question, state the baseline first, name the repeated work (the inner scan), then show how a hash map, two pointers or prefix sums removes it. The path from naive to optimal is what a phone screen on algorithmic efficiency lets you show.

Submitting the coding challenge without running your own edge cases

Before submitting, test an empty input, a single element, duplicates, negative or extreme values and a maximum-size input. Keep a brute-force solution to cross-check random small cases. A challenge's edge cases are described as the basis for follow-up questions, so fix them first.

Leaning on library helpers to hide the core algorithm

Practise writing counting with a hash map, sorting, binary search and the Knapsack DP table by hand, and explain the complexity of each line. Candidates report that comfort implementing core structures without library abstractions matters.

Defining WebSockets, long polling, sessions or REST without a scenario or trade-off

Attach each to a use case, such as a real-time messaging feature, and say what fails: connection limits and reconnects for WebSockets, repeated requests for long polling, session fixation or cookie theft for sessions. Answer why you chose it, not just what it is.

Going quiet when stuck, or claiming React fluency you cannot back up

Say what you have ruled out and what you will try next, since candidates are advised to think aloud on phone screens. For React, describe what you learned and a bug you hit, instead of claiming expertise; the reports describe quick learning of a new framework as acceptable.

Questions & practice

How would you optimize this algorithm from O(n^2) to O(n)?

Medium · Coding and Algorithmic Efficiency

Approach

1. Name the quadratic shape first: a nested loop that, for each element, rescans the rest of the array for a partner, a duplicate or a running total. The fix is almost always to remember what the outer loop has already seen.
2. Replace the inner scan with a hash map or hash set keyed on the value you need (for pair-sum, store each value and look up target minus the current value). One pass gives O(n) average time and O(n) extra space.
3. If the inner loop recomputes a range total, keep a prefix sum or a sliding window; if it searches for the next greater or smaller element, use a monotonic stack where each index is pushed and popped once, which is O(n) amortised.
4. Two pointers reach O(n) only on sorted input; if you must sort first the total becomes O(n log n), so say which one you are claiming.
5. Edge cases: empty or single-element input, duplicates (a value pairing with itself), negative numbers in window problems, and the hash map worst case of O(n) per lookup under heavy collisions.

Follow-up

• Can you get the same result in O(1) extra space, and what does that cost in time?
• What changes if the input arrives as a stream you can only read once?
• Walk me through why your monotonic stack solution is O(n) and not O(n^2).

Can you manipulate this array to achieve the desired output with minimal space complexity?

Medium · Coding and Algorithmic Efficiency

Approach

1. Ask whether you may mutate the input and whether output order must be kept; in-place with stable order and in-place with any order have different answers.
2. For filtering or compaction (remove duplicates from a sorted array, move zeros to the end) use a read pointer and a write pointer: one pass, O(n) time, O(1) extra space, and relative order is preserved.
3. For rotation by k, reverse the whole array, then the first k elements, then the rest: O(n) time and O(1) space, with k reduced modulo n first.
4. For three-way grouping use Dutch national flag partitioning (low, mid, high pointers); for values guaranteed in 1..n, mark seen values by negating or swapping into their index to find a missing or duplicate number without a hash set.
5. State that a recursive helper uses O(depth) stack space, so it is not O(1); test empty arrays, k larger than n, all-equal values and arrays that are already in the target order.

Follow-up

• Your partition is not stable. How would you keep the original order and what does it cost?
• How would you restore the input afterwards if you used the sign-marking trick?
• Does your solution still work if the array contains zeros or negative numbers?

Given a set of constraints, how would you implement a solution to a variation of the Knapsack problem?

Medium · Coding and Algorithmic Efficiency

Approach

1. Pin down the variant before coding: 0/1 (each item once), unbounded (unlimited copies), bounded counts, fractional, or subset sum and target-count versions; each changes the recurrence.
2. For 0/1 knapsack use dp[w] = max(dp[w], dp[w - weight] + value) over a 1D array, iterating capacity from high to low so each item is used at most once; iterate low to high for the unbounded variant. Time O(n * W), space O(W).
3. Say that O(n * W) is pseudo-polynomial: it grows with the numeric capacity, not its bit length. If W is huge but values are small, flip the table to minimum weight needed for each total value, O(n * total value).
4. Fractional knapsack is the only variant where the greedy ratio of value to weight is optimal (sort, O(n log n)); for 0/1 the greedy ratio can be wrong, and a two-item counterexample shows it.
5. To return the chosen items keep the 2D table or a choice bit per (item, capacity) and walk back from dp[n][W]; test capacity 0, items heavier than capacity and zero-value items.

Follow-up

• How would you handle item counts bounded at, say, up to 1,000 copies each without blowing up the item list?
• With only about 40 items but a capacity near 10^12, what would you do instead of the DP?
• How would you also count the number of distinct optimal selections?

What are the trade-offs of using different data structures for this specific search task?

Medium · Coding and Algorithmic Efficiency

Approach

1. Start from the access pattern: exact-match lookup only, range or nearest-neighbour queries, prefix matching, or top-k; how often the data changes relative to how often it is searched; and whether it fits in memory.
2. Hash set or map: O(1) average lookup and insert, O(n) worst case under collisions, no ordering, so no range or predecessor queries. Sorted array with binary search: O(log n) lookup, compact and cache-friendly, but O(n) insert.
3. Balanced BST (red-black or AVL, as in TreeMap): O(log n) lookup, insert and delete, plus ordered iteration, floor/ceiling and range queries, at a higher memory and pointer-chasing cost.
4. Trie for prefix and autocomplete search: O(L) per lookup in the key length, independent of n, but memory-heavy; a heap answers min, max or top-k only and is not a general search structure.
5. For very large membership checks, mention a Bloom filter: small, no false negatives, a tunable false-positive rate, and no deletion in the basic form.

Follow-up

• The data is read millions of times and updated once a day. Which structure do you pick now?
• How would you support both exact lookup and "all keys between A and B" at the same time?
• What changes if the dataset no longer fits in memory?

How do you approach problem-solving when you hit a technical roadblock?

Medium · Behavioral and Growth Mindset

Approach

1. Reproduce first: get the failure down to the smallest input or the fewest steps that trigger it, and read the actual error message and stack trace before forming a theory.
2. State a hypothesis and test one variable at a time. Bisect the search space: binary search over inputs, comment out halves of the code path, or run git bisect across commits to find the change that broke it.
3. Check assumptions explicitly: library and runtime versions, environment variables, configuration, the data the code really receives (log it or use a debugger), and whether the bug is in your code or a dependency.
4. Timebox the solo effort, then ask for help with a precise write-up: the expected and actual behaviour, the minimal repro, and what you have ruled out, so the person helping does not repeat your steps.
5. Tell it through one concrete example where you followed this sequence, and close with what you changed afterwards (a test that pins the bug, a log line, a doc note) so the same roadblock does not return.

Follow-up

• Tell me about a time this process did not work and you were stuck for days. What did you do?
• How do you decide when to stop digging and ask someone?
• How do you debug something that only happens in production and you cannot reproduce locally?

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?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

Can you draw a data flow diagram that links these components together logically?

Medium · System Design and Architecture

Approach

1. Fix the scenario and actors first (for a real-time messaging feature: sender client, recipient clients, server, storage) and list the user actions the diagram must cover, such as send, deliver, mark read and load history.
2. Draw components left to right: React client, load balancer, stateless API service, auth check, a WebSocket or long-polling gateway for push, a message queue or pub/sub for fan-out, the database of record and a cache for recent conversations.
3. Label every arrow with direction, protocol (HTTPS, WebSocket) and payload, and separate the synchronous path (client writes message, server persists, returns an id) from the asynchronous path (publish event, gateway pushes to recipients).
4. Mark where data is persisted, where it is only in flight, and the trust boundaries where authentication and input validation happen.
5. Walk one message end to end on the diagram, then name the failure points: recipient offline (store and deliver on reconnect), duplicate delivery (client-generated message id for dedupe) and ordering (per-conversation sequence number).

Follow-up

• Where in this diagram would you add a cache, and what would invalidate it?
• A recipient is connected to a different server instance. How does the message reach them?
• How do you make sure a message is not lost if the server crashes right after the client sends it?

How would you handle RESTful API interactions in a scalable way?

Medium · System Design and Architecture

Approach

1. Keep API servers stateless (session or token data in a shared store or the token itself) so any instance can serve any request and you scale horizontally behind a load balancer.
2. Model resources with the right verbs and status codes; GET, PUT and DELETE are idempotent by definition, POST is not, so accept an Idempotency-Key header on creates so retries do not double-write.
3. Paginate list endpoints with a cursor (keyset on an indexed column) rather than large OFFSETs, which make the database skip rows; cap page size.
4. Cut load with HTTP caching: Cache-Control for public reads, ETag with If-None-Match returning 304 Not Modified, and a CDN or reverse-proxy cache in front of hot endpoints.
5. Protect the service: per-client rate limits returning 429 with Retry-After, timeouts on every downstream call, client retries with exponential backoff and jitter that are safe for idempotent methods and for POSTs that carry an Idempotency-Key, and a versioning scheme (/v1 or a header) for breaking changes.

Follow-up

• How would you design pagination so that items inserted while a user is paging are not skipped or repeated?
• A client times out on a POST and retries. Walk me through how you avoid a duplicate record.
• Where would you put rate limiting, and how do you share counters across many API instances?

What are the differences and use cases for WebSockets versus Long Polling?

Medium · System Design and Architecture

Approach

1. WebSockets: an HTTP/1.1 Upgrade handshake (101 Switching Protocols) turns one TCP connection into a persistent, full-duplex channel; after that, each message carries only a small frame header, so latency and overhead are low in both directions.
2. Long polling: the client sends a request, the server holds it open until data arrives or a timeout fires, responds, and the client immediately reissues. It is plain HTTP, so it passes through proxies and firewalls easily, but every message pays a full request and there is a gap between response and the next request.
3. Use WebSockets for frequent, bidirectional, low-latency traffic (chat, collaborative editing, live presence, games); long polling for infrequent updates, restrictive networks, or as a fallback. Mention Server-Sent Events when only server-to-client push is needed.
4. Scaling WebSockets means stateful connections: track which node holds each user, fan out through pub/sub (for example Redis) across nodes, send ping/pong heartbeats, and set load balancer idle timeouts above the heartbeat interval.
5. With either approach, handle reconnects: the client resumes from its last seen message id or cursor so nothing is missed or duplicated during a dropped connection.

Follow-up

• You have 100,000 concurrent WebSocket connections across ten servers. How does a message for one user reach the right server?
• How do you authenticate a WebSocket connection, given that browsers cannot set custom headers on the handshake?
• What happens to messages sent while a long-polling client is between requests?

How do you manage sessions and cookies in a secure, performant manner?

Medium · System Design and Architecture

Approach

1. Choose the model: a server-side session (an opaque random id from a cryptographically secure generator, 128 bits or more, stored in a cookie, with session data in a store such as Redis with a TTL) versus stateless signed tokens such as JWTs, which avoid a lookup but are hard to revoke before expiry.
2. Set cookie attributes deliberately: HttpOnly so scripts cannot read the session (limits damage from XSS), Secure so it is only sent over HTTPS, SameSite=Lax or Strict against CSRF (SameSite=None requires Secure), plus narrow Path and Domain and an explicit Max-Age.
3. Regenerate the session id on login and privilege change to prevent session fixation; add CSRF tokens for state-changing requests where SameSite alone is not enough; do not keep tokens in localStorage, which any script on the page can read.
4. Use both an idle timeout and an absolute lifetime; on logout delete the server-side session, not just the cookie. For JWTs, keep access tokens short-lived and rotate refresh tokens, with a denylist for forced logout.
5. For performance, keep cookies small (browsers cap a cookie at roughly 4 KB and it rides on every request), serve session lookups from an in-memory store, and avoid a database read on every request.

Follow-up

• A user changes their password. How do you log out all of their other sessions?
• Your front end and API are on different subdomains. What cookie settings and CORS settings do you need?
• Compare the blast radius of a stolen JWT with a stolen server-side session id.

Explain how you would architect a full-stack application to ensure it remains maintainable as features scale.

Medium · System Design and Architecture

Approach

1. Start with a modular monolith organised by feature (users, billing, messaging), each with its own routes, service layer and data-access layer; split into separate services only when a module needs independent deploys or scaling, because each split adds network calls, ops work and distributed failure modes.
2. Keep business logic out of controllers and React components: thin HTTP handlers, services that hold the rules, and repositories that own queries, so each layer can be tested on its own.
3. On the React side, group components by feature, separate server data (fetched and cached through a data-fetching layer) from local UI state, and share a typed API contract, for example an OpenAPI schema that generates the client.
4. Make change safe: versioned database migrations, unit tests on services, integration tests on the API, a CI pipeline that runs them on every change, and feature flags so unfinished work can ship dark.
5. Add observability from the start (structured logs with a request id, metrics, tracing) and name the trade-off: more structure slows the first features but keeps the tenth one cheap.

Follow-up

• At what point would you split a module out into its own service, and what would you watch for afterwards?
• How do you change a database column used by both the old and new versions of the API during a rolling deploy?
• How would you stop shared React components from turning into a dumping ground as the team grows?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

1. Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
2. Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
3. Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
4. The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

• Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
• How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

Days 2 and 3 cover the reported algorithm questions and days 4 and 5 the web-architecture questions, day 6 covers behavioral stories and debugging, and day 7 is a spoken run-through of all three rounds.

Day 1 — Map the loop and set a baseline

• Write out the three reported rounds (Online Coding Challenge, Technical Phone Screens, On-site Experience) and next to each list the question types in this guide that practise it.
• Solve one quadratic problem of your choice unaided, write its complexity, and note where you hesitated. This is your baseline for the week.
• List the web fundamentals you can explain without notes (REST, HTTP, cookies, WebSockets) and mark the two weakest.

Deliverable: A one-page loop map with a question-type list per round, a baseline solution with its complexity, and a ranked list of weak web topics.

Day 2 — Quadratic to linear, and arrays in place

• Rewrite pair sum, duplicate detection and longest subarray with a given sum from quadratic to linear using a hash map, two pointers or prefix sums, and write the complexity of each.
• Solve three in-place array tasks (remove duplicates from a sorted array, move zeros to the end, rotate by k using reversals) with constant extra space, and note each invariant.
• Say what happens to each solution if the input grows 100 times.

Deliverable: Six solved problems with before and after complexity and a one-line invariant for each in-place task.

Day 3 — Knapsack variations and data-structure trade-offs

• Implement 0/1 Knapsack as a 2D table, then shrink it to a one-dimensional array iterated backwards, and explain why the direction matters.
• Solve one variation by hand (subset sum, unbounded knapsack or a count-the-ways version) and state time and space.
• For one search task, compare an unsorted array, a sorted array with binary search, a hash map and a balanced tree on lookup, insert, memory and ordered queries.

Deliverable: Two Knapsack implementations with complexity notes and a trade-off table for the search task with a recommended choice.

Day 4 — Web protocols and state

• Write a one-page comparison of WebSockets and long polling with a real-time messaging scenario, reconnect behavior and scaling concerns for each.
• List what makes a REST API scale: idempotent methods, pagination, caching headers, statelessness, rate limiting and versioning, with one sentence each.
• Outline session handling: cookie attributes (HttpOnly, Secure, SameSite), server-side session store versus signed tokens, expiry, rotation on login and invalidation on logout.

Deliverable: A three-section reference sheet (real-time transport, REST at scale, sessions and cookies) you can recite from memory.

Day 5 — Data flow, structure and a React prototype

• Sketch a data flow diagram for a real-time messaging feature: client, API, persistence and a push channel, labeling protocol and state at each hop. Narrate it aloud.
• Describe how you would organize a full-stack application so it stays maintainable as features grow: layers, shared types, error handling and testing.
• Build a small React feature from the documentation alone (a form, a list and a fetch with loading and error states), then write a short README of what you cut.

Deliverable: A labeled data flow diagram, a one-page maintainability outline and a working React prototype with a trade-off README.

Day 6 — Behavioral stories and the roadblock routine

• Write outlines for the large-input failure, learning React on a deadline, and code review feedback stories: situation in two sentences, then decisions, evidence and result.
• Write your answers on motivation and a growth plan as ordered steps, each with a way to check progress.

Deliverable: Three story outlines with numbers, a written growth plan and a roadblock routine tested once on the practice debugging exercise.

Day 7 — Spoken run-through of all three rounds

• Solve two fresh algorithm problems aloud under a time limit you set, saying baseline, bottleneck, improvement and edge cases, then write a few of your own edge tests as if submitting.
• Answer one WebSockets versus long polling question and one Knapsack variation aloud as if on a phone screen, and recover on purpose from a deliberate stall by narrating.
• Tell two behavioral stories aloud and cut each to the decision and the result, then write your questions for senior people.

Deliverable: A recorded or written run-through with the list of answers that needed a restart, and a final list of questions for senior people.

Behavioral and learning-speed preparation

Candidates report behavioral questions about learning a new technology under a deadline, approaching a roadblock, motivation and professional growth, and handling code review feedback. Pick stories that show how you learn quickly, how you change course when your first attempt fails, and how you take feedback in a team. Use real decisions with numbers, and say what you would change.

1. How do you approach problem-solving when you hit a technical roadblock?

How do you handle edge cases when your initial implementation fails on large inputs?

Medium · Coding and Algorithmic Efficiency

Approach

1. Open with a real incident where code passed the small samples and failed at scale, and name the failure type: time limit, memory, stack overflow or integer overflow. Each has a different fix, so naming it shows you diagnosed rather than guessed.
2. Describe diagnosis before the fix: reproduce with a generated large input, count operations or measure time at several sizes, and compare growth with what you expected. If ten times the input took roughly a hundred times as long, the solution is quadratic somewhere, and you find the loop responsible.
3. Match the fix to the cause: replace repeated scans with a hash map or prefix sums, turn deep recursion into iteration or add memoization, stream data instead of loading it all, and widen the integer type or use modular arithmetic for overflow.
4. Describe the edge-case suite you kept afterward: empty input, one element, all duplicates, already sorted and reverse sorted, maximum size and extreme values, plus a brute-force version used to cross-check the optimized one on random small inputs.
5. Close with measured results and one changed habit, such as estimating worst-case operations from the stated limits before writing code. The mistake that sinks this answer is saying you test edge cases without a concrete incident.

Follow-up

• How would you confirm the optimized version still returns the same answers as the original?
• How could you have predicted the large-input failure before it ran?
• What changes if the input no longer fits in memory?

Tell me about a time you had to learn a new technology (e.g., React) under a tight deadline.

Medium · Behavioral and Growth Mindset

Approach

1. Pick a real deadline and state it in two sentences: what had to ship, by when, and what you already knew (for example JavaScript or another UI framework) so the transfer is clear. Name React or the actual technology rather than saying a new tool.
2. Show how you learned, not just that you did: you listed the smallest concept set needed (components, props, state, useState and useEffect, rendering lists, form handling, fetching data), read the official documentation with a working example beside it, and built one thin end-to-end slice before widening.
3. Describe the scope decisions. Say what you left rough, such as styling, test coverage or error states, and what you refused to cut: the core requirement working and its edge cases handled. A prototype that functions beats a polished one that does not.
4. Include something you got wrong and how you found it, for example an effect with a bad dependency array causing a render loop, and how you debugged it. This is the strongest proof that you really learned the tool.
5. Finish with the outcome and what happened after: what shipped, what you refactored later, and how you would speed up learning next time, such as asking a teammate to review the riskiest part. Avoid a story that is only long hours or that claims fluency.

Follow-up

• What did you deliberately leave out, and what did it cost later?
• How did you check the code was correct when you did not yet know the framework well?
• What would you do differently with twice the time?

What motivates you to pursue engineering excellence, and how do you plan your professional growth?

Medium · Behavioral and Growth Mindset

Approach

1. Anchor motivation in behaviors rather than adjectives. Pick two or three habits that show it, such as writing a failing test before a fix, reading profiler output before optimizing, keeping pull requests small, or doing a write-up after an incident. Tell one story where a habit changed an outcome.
2. Connect it to the role as candidates describe it: data structures and algorithms, web architecture, full-stack work and React or a similar framework. Say where you are strong in that mix and which part you are still building.
3. Give the growth plan as ordered, checkable steps: the next skill, how you will get it (a project, reading a mature codebase, taking on code review, a stretch task at work), and how you will know it worked. A list of courses is not a plan.
4. Hold both halves of the question together: why you care about the craft, and how you plan to develop. End with how this kind of role fits that plan using facts you actually have, not flattery you cannot support.
5. The mistakes to avoid are platitudes such as being passionate about clean code with no example, and a plan so vague that it could belong to anyone.

Follow-up

• Tell me about a time your quality standard slowed you down, and how you balanced it with shipping.
• Which item on your growth plan is behind, and why?
• What support would you want from a lead to keep that plan moving?

How do you handle feedback from a peer or lead during a code review?

Medium · Behavioral and Growth Mindset

Approach

1. Choose a real review where a comment changed your code. State the comment, your honest first reaction, and the steps you took: reproduce the concern, check it against the code and tests, then either change the code or reply with evidence.
2. Show a split record. Include a comment you accepted and what it taught you (a missed null path, a leaked connection, an unclear name), and one you respectfully disagreed with, settled with evidence such as a benchmark, a requirement or a short conversation instead of repeated thread replies.
3. Cover the mechanics: answer every comment, push follow-up commits, add a test for the case the reviewer found, and ask a clarifying question when a comment is vague instead of guessing.
4. Add that you review others too, and how you phrase it: the observation, the reason it matters, and a suggestion. Mention keeping your own pull requests small so they are easy to review.
5. The mistakes that sink this answer are claiming you always take feedback well with no example, or telling a story where the reviewer was wrong and you won.

Follow-up

• Tell me about a review comment you disagreed with and how it ended.
• What do you do when feedback is vague or two reviewers contradict each other?
• How do you structure your own pull requests so they are easy to review?