The reported questions are about your own experience, not puzzles. Candidates describe prompts on managing Ruby-based applications, debugging infrastructure problems under pressure, keeping code quality and scalability up in production, tuning a database under heavy traffic, and mitigating common security vulnerabilities. Two example scenarios are also reported: walking through the lifecycle of a request in your current architecture, and refactoring a legacy module so it is easier to maintain. Each is answered best with a real project you can describe in detail, so your first job is to choose three or four projects and know them cold: the stack, the numbers, the decisions and the mistakes.
The teamwork questions follow the same pattern. Candidates report prompts about running a project with unclear requirements, handling a peer challenging your code or design, prioritising across several stakeholders, and keeping documentation and knowledge sharing healthy in a team. Reports also say that explaining technical roadblocks to non-technical stakeholders matters, and that you should lead with the problem, your action and a measurable result. Build every story in that order and keep a real number in it.
Reports repeatedly mention that similar questions can be asked by different interviewers across the technical rounds, and that the process can run for several weeks. That makes consistency a preparation task: write down the facts of each story once (dates, metrics, team size, your exact role) and reuse them, adding fresh detail rather than a different version. Topic tags on the reports include Ruby, full-stack and web development, infrastructure support and service desk or IT support, so keep one story about keeping a system alive, not only about building features. Nice-to-have skills reported are cloud infrastructure and automated testing, so be ready to say how your tests and deploys protect production.
HR Screening
reportedCandidates describe this stage as an initial screening run by HR to judge fit for the role. No technical format is reported for it. Treat it as the place where your background, your reasons for the move and your logistics need to be clear, and where you learn what the technical rounds will look like.
What to demonstrate
- Fit for the Software Engineer role as reported for this screening
- How clearly you summarise your background in Ruby, full-stack or web work
- Whether your location, timing and expectations line up with the role
How to prepare
- Write a two-minute walk through your CV that names the stack you have run in production (Ruby or your equivalent) and one outcome you can quantify.
- Prepare a specific reason for applying to Booth for this role, drawn from the work the role is reported to cover: web, full-stack and infrastructure support.
- Have notice period, location constraints and salary expectations ready, then ask what the technical rounds will cover and how many there are.
- Write one sentence on each of your three or four best projects so the same facts come out every time you are asked.
Technical Rounds
reportedCandidates describe multiple technical assessments that test depth of knowledge and consistency, and warn that you may be asked similar questions by different interviewers. Reported evaluation areas are technical depth (system architecture, code optimisation, security), plus adaptability and collaboration. Prepare each answer as a concrete project story and keep its facts identical between sessions, adding new detail each time.
What to demonstrate
- Depth in your primary language and framework, and in the infrastructure underneath it
- System architecture, code optimisation and security practices, the reported depth topics
- Consistency of your answers across different interviewers
- Handling ambiguity and peer review, the reported adaptability topics
How to prepare
- Rehearse the request-lifecycle walkthrough aloud for your current system: DNS and load balancer, web server, framework routing, middleware, controller, database and cache, background jobs, response.
- Prepare the database optimisation story with the slow query, the tool that found it, the fix and the before and after numbers, then practise the PracHub SQL index questions.
- Write a one-page security list for a web app (injection, XSS, CSRF, broken access control, secrets, vulnerable dependencies), each with the concrete mitigation you have used.
- Keep a fact sheet per story and re-read it before every session so repeated questions get consistent answers.
PracHub editorial advice for the preparation topics above.
Giving a different version of the same story to different interviewers
Reports say similar questions can recur across the technical rounds. Write down dates, metrics, team size and your exact role for each project once, and reuse those facts, adding new detail rather than changing them.
Answering the Ruby and full-stack question with a list of technologies and no decisions
Pick one application and describe what you owned: upgrades, deploys, migrations, monitoring. Include one trade-off you chose, with its evidence and a measured result, and say honestly where your experience is thinner.
Opening the database optimisation answer with 'add an index'
Begin with measurement: slow query log or pg_stat_statements, then EXPLAIN ANALYZE. Then name the fix, its write and storage cost, and the before and after numbers. Cover caching, replicas and pagination as alternatives.
Answering the security question with an acronym list and no mitigation
For each vulnerability give the attack and the fix you have used: parameterised queries for SQL injection, output escaping and CSP for XSS, CSRF tokens, authorisation checks on every object lookup, secrets outside the repository, and dependency scanning.
Debugging under pressure answered as a calm checklist with no result, or as a hero story with no method
Describe the sequence you followed: what changed, what you ruled out and in which order, how you mitigated before you fixed the cause, and what you added afterwards. Lead with the problem, your action and a measurable result.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Canonicalise a request body into a stable idempotency fingerprint
idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.
Approach
- Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
- Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
- Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
- Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.
Follow-up
- A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
- Where does the fingerprint get computed relative to request decompression and the body-size limit?
Find overlapping job attempts and peak concurrency from lease records
A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.
Approach
- Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
- For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
- For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
- Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.
Follow-up
- A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
- Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?
Track a rolling failure rate per destination for circuit decisions
The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.
Approach
- Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
- Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
- State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
- Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.
Follow-up
- The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
- A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?
Write the update path that detects a concurrent edit
resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.
Approach
- One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
- Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
- State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
- Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.
Follow-up
- A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
- Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?
Explain why the owner filter ignores the listing index
The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.
Approach
- Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
- For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
- Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
- Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.
Follow-up
- 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
- A dashboard runs this for 40 owners in one page load. What changes about the design?
Explain your process for ensuring code quality and scalability in a production environment.
Explain your process for ensuring code quality and scalability in a production environment.
Approach
- Describe the merge gates in order: small reviewable pull requests, a linter and static analysis (RuboCop for Ruby), unit tests for business logic, integration tests around the database and external calls, and a CI run that must pass before merge. Point the tests at the risky paths instead of chasing a coverage percentage.
- Make releases reversible: feature flags, canary or staged rollouts, and backward-compatible schema changes using expand and contract (add the new column, backfill, switch reads and writes, drop the old column in a later release), so the previous app version keeps working against the new schema.
- For scalability, keep app servers stateless so they scale horizontally behind a load balancer, move slow or retryable work to background jobs (Sidekiq, for example) with idempotent handlers, and add caching only where you can state the invalidation rule.
- Measure instead of guessing: metrics, structured logs and traces, alerts on user-facing symptoms such as error rate and p95/p99 latency, and load tests before big launches. Show you can find N+1 queries and fix them with eager loading (includes in ActiveRecord) or a better index.
- Name a trade-off you have made, such as shipping behind a flag with thinner tests to hit a date and then paying it back, and how you kept that debt visible.
Follow-up
- How would you add a NOT NULL column to a large, heavily written table without downtime?
- p99 latency doubled after a release even though every test passed. How do you find out why?
- Where do you draw the line between a unit test and an integration test in a Ruby web codebase?
What are the most common security vulnerabilities you encounter, and how do you mitigate them?
What are the most common security vulnerabilities you encounter, and how do you mitigate them?
Approach
- Frame the answer with OWASP Top 10 categories, but lead with the ones you have actually fixed (injection, broken access control, XSS, CSRF, leaked secrets, vulnerable dependencies) and what you changed each time.
- Injection: always use bind parameters. In ActiveRecord, write where(email: value) or where("email = ?", value) and never interpolate user input into a SQL string. Use the same principle for shell commands and LDAP or NoSQL queries.
- Access control: authorise every request on the server against the object's owner. Scope lookups (current_user.orders.find(id)) so changing an ID in the URL cannot expose another user's record (IDOR), deny by default, and block mass assignment with strong parameters (permit).
- Browser-side attacks: rely on context-aware output escaping (Rails ERB escapes by default, while raw and html_safe bypass it) plus a Content-Security-Policy against XSS. Use anti-CSRF tokens (protect_from_forgery) with SameSite cookies, and mark session cookies HttpOnly and Secure.
- Secrets and supply chain: keep secrets in a secrets manager rather than git and rotate any that leak, give the app's database and cloud roles least privilege, scan dependencies (bundler-audit) on a patch cadence, and hash passwords with bcrypt or argon2, never a fast unsalted hash.
Follow-up
- A user can view another customer's invoice by changing the ID in the URL. How do you fix it, and how do you find other endpoints with the same bug?
- How would you store user passwords, and why not plain SHA-256?
- An API key was pushed to a public repository. What do you do first, and in what order?
How do you approach debugging complex infrastructure issues under pressure?
How do you approach debugging complex infrastructure issues under pressure?
Approach
- Mitigate before you explain: restore service first by rolling back the last deploy, turning off a feature flag, failing over or scaling out, and say out loud that root cause comes after users are unblocked.
- Build a timeline of what changed and when (deploys, config or secret changes, certificate expiry, dependency upgrades, traffic spikes), then line it up against the moment latency, error rate, traffic or saturation moved on the dashboards.
- Bisect the request path one layer at a time (DNS, load balancer, app servers, database, cache, queue). Correlate logs by request ID, and pick checks that rule a whole layer in or out whichever way they come back.
- Check the resources that usually run out: disk, file descriptors, memory (OOM kills), CPU and connection pools. In a Ruby app, for example, more Puma threads than ActiveRecord pool slots produces ActiveRecord::ConnectionTimeoutError under load even though the database itself looks healthy.
- Close the loop: separate the trigger from the underlying cause, write a blameless postmortem, and add the alert or runbook step that would have caught it sooner.
Follow-up
- Errors jumped right after a deploy, but rolling back did not bring them down. What do you look at next?
- How would you debug a failure that only happens intermittently, or on one host out of many?
- How do you keep non-technical stakeholders updated while the incident is still open?
Seven days built from the two reported stages and the nine reported questions, with PracHub's reviewed practice questions on indexing, concurrency and job handling as hands-on practice. Early days cover your stories and the technical topics, and the last day runs a full mock.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and build your fact sheet
- Write the reported sequence (HR Screening, then Technical Rounds) and mark which one you are least ready for.
- Choose three or four projects and write one fact sheet each with stack, your role, team size, dates, metrics and one failure.
- Write your two-minute CV walk and your reason for applying for this role.
Deliverable: A one-page loop map, a fact sheet for each chosen project, and a written two-minute CV walk.
02Full-stack and Ruby experience
- Write the full-stack and Ruby-based application story in the order of layers, upgrades, deploys, monitoring and a measured result.
- Rehearse the request-lifecycle walkthrough aloud from load balancer to response for your current system.
- Pick one legacy module you know and write how you would refactor it: tests first, small steps, how you would prove behaviour did not change.
Deliverable: A written application story, a spoken request-lifecycle walkthrough, and a short legacy-module refactor plan.
Practice prompt ↗03Database optimisation
- Write the database optimisation story with the slow query, the tool that found it, the fix and the before and after numbers.
- Work through the PracHub practice question on why the owner filter ignores the listing index, and write the corrected index.
- Work through the PracHub practice question on an update path that detects a concurrent edit, and write the version-column check.
Deliverable: A database optimisation story with numbers, one corrected index, and one working concurrent-edit update.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Debugging, code quality and security
- Write your debugging-under-pressure sequence: what changed, ruled out, mitigated, fixed, prevented.
- Write your code quality and scalability process for production: tests, review, deploy, monitoring, load limits.
- Write the security list for a web app with attack and mitigation per item, then solve the PracHub rolling-failure-rate and job-attempt practice questions for hands-on coding.
Deliverable: A debugging runbook, a code quality and scalability checklist, a security attack-and-fix list, and two solved practice questions.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗05Ambiguity and prioritisation stories
- Write the unclear-requirements story: assumptions, smallest slice, decision log, result.
- Write the stakeholder prioritisation story with the options table you showed the decision-maker.
- Say both aloud and cut each to under two minutes while keeping the numbers.
Deliverable: Two written and recorded stories (unclear requirements and stakeholder prioritisation) with numbers kept in.
Practice prompt ↗Practice prompt ↗06Feedback and knowledge sharing
- Write the peer-challenged-your-design story using a real review where you changed your mind or held your position with evidence.
- List the documentation and sharing practices you have run, with one instance where each helped.
- Solve the PracHub idempotency-fingerprint practice question to keep coding sharp, then compare your story facts against Day 1 for consistency.
Deliverable: A feedback story, a documentation practices list with examples, one solved practice question and a consistency check against the fact sheets.
Practice prompt ↗Practice prompt ↗Practice prompt ↗07Full mock and questions to ask
- Run a mock of the HR screening, then a technical session, with someone asking the reported questions in a shuffled order and repeating one question later.
- Check that the repeated answer keeps the same facts while adding new detail.
- Write the questions you will ask at the end of each round and a log template for dates, interviewers and follow-ups.
Deliverable: A recorded mock with notes on consistency, a list of questions for each round, and a log template for tracking the process.
Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report that the teamwork questions cover unclear requirements, peer feedback, prioritising across stakeholders, and documentation and knowledge sharing. Reports also stress explaining technical roadblocks clearly to non-technical stakeholders and leading with the problem, your action and a measurable result. Prepare each story once with fixed facts, since similar questions can come up with several interviewers.
Describe your experience with full-stack development and managing Ruby-based applications.
Describe your experience with full-stack development and managing Ruby-based applications.
Approach
- Choose one application you owned end to end and name its layers: the Ruby (or equivalent) version and framework, the database, background jobs, the front end, hosting and deployment. Say which parts you built and which you maintained.
- Show that you managed it, not only wrote it: dependency and version upgrades, applying security patches, keeping the test suite trustworthy, handling migrations, and what you watched in production.
- Give one decision with a trade-off, for example a monolith kept whole versus a service split out, or a gem replaced with your own code, and the evidence that led you there.
- Close with a measurable result such as error rate, response time, deploy frequency or upgrade completed. Be honest about layers where you are weaker, and say how you would close the gap quickly.
Follow-up
- What was the hardest upgrade or migration you ran on that application, and how did you de-risk it?
- Where is the boundary between your front end and back end responsibilities, and where did that boundary cause problems?
- What would you change about that architecture today?
How do you handle database optimization when dealing with high-traffic applications?
How do you handle database optimization when dealing with high-traffic applications?
Approach
- Tell it as a story, but with the technical sequence: measure first. Find the worst queries by total time using the slow query log or pg_stat_statements, then read EXPLAIN ANALYZE rather than guessing.
- Name the fixes you actually applied and why each fit: a composite index ordered by equality columns then range or sort columns, removing N+1 queries with eager loading or joins, keyset pagination instead of large OFFSET, batching writes, and trimming selected columns.
- State the system-level options and their costs: caching hot reads (staleness and invalidation), read replicas (replication lag), connection pooling, and avoiding long transactions that hold locks. Add that new indexes slow writes and take space, and that indexes can be built without blocking writes (CREATE INDEX CONCURRENTLY in Postgres).
- Give the evidence: before and after latency (p95 if you have it), query counts and database load, and how you rolled the change out and watched for regressions.
Follow-up
- How did you decide between adding an index and caching the result?
- What happens to write throughput when you add that index, and how did you check?
- How would you find N+1 queries before they reach production?
Tell me about a time you had to manage a project with unclear requirements.
Tell me about a time you had to manage a project with unclear requirements.
Approach
- Choose a project where the requirements were truly vague and you had to act, not one where you waited for clarity. Describe the situation in two sentences: who was asking, what was unclear, what was at stake.
- Show how you reduced the ambiguity: the questions you asked, the assumptions you wrote down and had confirmed, and the smallest slice you built or sketched to get a reaction early.
- Describe how you kept stakeholders aligned: a short written decision log or spec, checkpoints, and how you handled a requirement that changed after you had started.
- End with the result and a lesson, for example what shipped, what you cut, and what you would clarify earlier next time. The mistake that sinks it is either 'I guessed and built everything' or 'I waited until someone told me exactly what to do'.
Follow-up
- Which assumption turned out to be wrong, and what did it cost?
- How did you decide what to build first when you could not get answers?
- How did you communicate the changing scope to non-technical stakeholders?
How do you handle feedback when your code or design is challenged by a peer?
How do you handle feedback when your code or design is challenged by a peer?
Approach
- Pick a real disagreement from a code review or design review where you had a stake, ideally one where you were partly or fully wrong. A story where you were simply right sounds rehearsed.
- Show the behaviour: you asked for the reasoning behind the challenge, restated their point to confirm you understood it, and separated the code from yourself.
- Show how you resolved it with evidence rather than seniority: a benchmark, a failing test, a production metric or a small prototype. If the peer was right, say what you changed; if you held your position, say what data you used and how you kept the relationship intact.
- Give the outcome and a lasting habit, such as smaller pull requests, a written design note before coding, or a review checklist.
Follow-up
- Tell me about a time you were certain you were right and turned out to be wrong.
- How do you give feedback when you think a peer's design is flawed?
- What do you do when two reviewers give conflicting feedback on the same change?
Describe a situation where you had to prioritize tasks while dealing with multiple stakeholders.
Describe a situation where you had to prioritize tasks while dealing with multiple stakeholders.
Approach
- Set up the conflict concretely: name the stakeholders, what each wanted, and why the requests could not all be done. Keep the context to a few sentences.
- Show how you ranked the work: impact, deadline, dependency, effort and risk, and who had the authority to decide. Make the trade-off visible by laying the options out in writing for the decision-maker rather than choosing silently.
- Describe how you communicated what would slip and why, in plain language for non-technical stakeholders, including any technical roadblock behind the delay.
- Close with the outcome and what you would do differently, and avoid the answer that says you did everything for everyone or that you used a framework with no people in it.
Follow-up
- Who made the final call, and what if they had chosen differently from your recommendation?
- What did you tell the stakeholder whose request was dropped or delayed?
- How do you handle a new urgent request that arrives mid-sprint?
How do you maintain documentation and ensure knowledge sharing within your engineering team?
How do you maintain documentation and ensure knowledge sharing within your engineering team?
Approach
- Start with the mechanisms you actually use, not a statement of values: a README and setup guide in each repository, runbooks for operating the system, short design or decision records, and docs that change in the same pull request as the code.
- Cover knowledge sharing beyond writing: code review as teaching, pairing on unfamiliar areas, short walkthroughs of new systems, and incident write-ups that record cause and fix.
- Give one specific instance where it paid off, such as a new engineer deploying in their first week from your onboarding guide, or an on-call engineer resolving an incident from a runbook. Say how you checked that the documents were accurate.
- Address decay: who owns each document, how stale pages are found and deleted, and keeping the habit up when the team is busy.
Follow-up
- How do you keep documentation from going stale?
- How would you improve knowledge sharing on a team where one person holds all the context?
- What do you write down for a decision that will be questioned later?
- 01
Tell me about a time you had to manage a project with unclear requirements.
- 02
How do you handle feedback when your code or design is challenged by a peer?
- 03
Describe a situation where you had to prioritize tasks while dealing with multiple stakeholders.
- 04
How do you maintain documentation and ensure knowledge sharing within your engineering team?
- 05
Describe your experience with full-stack development and managing Ruby-based applications.
- 06
How do you handle database optimization when dealing with high-traffic applications?
How long should I expect the Booth interview process to last?
Candidates report two stages, an HR screening and technical rounds, over roughly 2-4 weeks, though reports also say it can stretch to several weeks or even months. Track your application status and follow up at reasonable intervals, and keep your other applications moving.
Booth Software Engineer candidate reports ↗Will I be asked the same questions more than once?
Candidates report that similar technical questions can come up in different rounds. Keep a fact sheet for each story and reuse the same facts each time, adding fresh detail when you have it, so your answers stay consistent.
Booth Software Engineer candidate reports ↗What should I study first?
Start with the stack named in the reports: Ruby or your equivalent, full-stack and web development, and infrastructure support. Then cover the reported depth areas: system architecture, code optimisation and security. Day 3 and Day 4 of the plan cover database optimisation, debugging and security.
Booth Software Engineer candidate reports ↗Is there a coding challenge or take-home?
Reports describe the technical rounds as questions about experience, architecture and process, and none mention a take-home or a live coding challenge. Ask the recruiter what the technical rounds will cover, and keep some coding practice running in case. The PracHub practice questions in the plan are there for that.
PracHub Software Engineer practice ↗How do I answer the security question without sounding like a checklist?
Pick the vulnerabilities you have really handled and give each as attack, then fix: parameterised queries for injection, output escaping for XSS, CSRF tokens, authorisation on every record lookup, secrets management and dependency updates. One real incident or review finding is worth more than ten names.
Booth Software Engineer candidate reports ↗What should I ask the interviewers?
Prepare questions about the team's actual work: how releases and on-call are handled, how the stack is tested, and what the first projects look like. Reports recommend having thoughtful questions ready for the end of each round.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01Booth Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
CoreWeave Software Engineer Interview Guide
Failure-handling practice for CoreWeave software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Confluent Software Engineer Interview Guide
Concurrency exercises for Confluent candidates: check-then-act races, deadlock from inconsistent lock ordering, and why two individually atomic operations do not compose into an atomic update.
Capital One Software Engineer Interview Guide
Code-reading and review practice for Capital One candidates: tracing unfamiliar control flow, finding the invariant a function quietly depends on, and separating a correctness defect from a matter of taste.