Ashby Project Deep Dive Interview: Project Selection and Technical Trade-Offs

For an Ashby project deep dive interview, choose a project you can explain from the user problem down to an implementation decision and back to an observed result. A recognizable technology stack is useful context; your ability to defend what you personally decided is the substance of the conversation.

This guide helps you choose between plausible projects and rehearse the follow-up questions that expose gaps. Evidence boundary: the interview facts below come from Ashby's official engineering preparation page. We have not verified enough independent, same-cycle candidate reports to describe a universal current interview loop or offer candidate-based pass-rate claims.

What Ashby's Official Guidance Establishes

Official facts: Ashby's engineering page, last updated July 25, 2025, describes a short project discussion in an introductory call and a longer final-round discussion. Candidates lead while interviewers interrupt to explore details. The page emphasizes projects where the candidate led important decisions, can explain implementation and business context, and knows what happened after release.

Slides and diagrams are optional communication aids. The same project can be used again if it supports sufficient depth. If selection is difficult, Ashby invites candidates to send a hiring manager a couple of short project descriptions. Its examples distinguish work with meaningful product-driven decisions from technology changes that reveal little business judgment. Read the full official Engineer Past Projects Deep Dive guidance, and use your invitation for the applicable schedule and instructions.

The rest of this article is editorial preparation guidance, not Ashby's internal scoring rubric. It turns that public context into exercises you can apply to your own experience.

Choosing Between Three Plausible Projects

Imagine an engineer considering these three stories.

Project	Evidence the engineer can explain	Main weakness	Preparation judgment
Grant-review workflow	Personally designed application revisions, review assignments, and a staged customer rollout	Must explain a domain unfamiliar to interviewers	Strong primary option because decisions connect to a specific user problem
Database migration	Implemented backfill and reconciliation; remembers operational failure cases	The initial reason for migration is vague	Useful if the engineer can establish the customer or operating constraint behind the move
Observability prototype	Built an elegant dependency map and demonstrated it internally	Left before adoption; does not know production outcomes	Possible supporting example, with an explicit evidence gap

The grant workflow wins in this fictional comparison because the engineer can follow a complete chain. Program administrators needed reviewers to assess revised applications without confusing old and new feedback. The engineer chose a versioned representation, implemented the transition rules, worked through a release problem, and observed administrators using it.

That story offers several meaningful places to go deeper: why feedback attaches to a revision, how permissions work, how concurrent edits are handled, and how users discover that a decision concerns an older submission. A modest product can support substantial engineering discussion.

The migration could become the better choice if its missing context is recovered. Perhaps the old database could not support customer-specific retention rules without expensive operational work. Perhaps the engineer evaluated extending the existing system before recommending replacement. Those facts would change the story. “We moved because the new database scales” leaves the essential reasoning unexplained.

For the prototype, do not turn a demonstration into a production success. You can describe the problem investigated, design choices, and observed feedback. You cannot supply adoption or reliability results you never saw. If another project has comparable depth and a known outcome, it may provide more material for this particular conversation.

Build a Decision Record Before a Slide Deck

For each candidate project, write one consequential decision on a blank page. Under it, record the constraint, realistic alternatives, evidence available at the time, choice, accepted cost, and outcome. If you can only fill in the technology name, investigate further before choosing the project.

For the fictional grant workflow, the decision record might read:

• Constraint: administrators need to explain which submitted content a reviewer assessed, even after an applicant revises it.
• Alternatives: overwrite the application, store complete immutable revisions, or reconstruct history from individual changes.
• Choice: immutable submitted revisions with review assignments referencing a revision identifier.
• Accepted cost: more storage and explicit handling of feedback on older revisions.
• Validation: tests for revision changes during review, plus a pilot with administrators checking real review histories.

The alternatives need to be credible. Overwriting is simpler when history is irrelevant. A change log may be appropriate when reconstructing state is already a well-supported capability. Explain why your circumstances favored the chosen design; avoid claiming the alternative is inherently foolish.

Also separate decisions you made from decisions you inherited. An honest boundary could be: “The team already used a relational database. I chose the revision model and transaction boundary within that constraint. Another engineer owned the notification service.” This still demonstrates ownership without claiming the entire platform.

A Project Story That Survives Interruptions

The following dialogue is a fictional rehearsal, not an Ashby transcript. Its purpose is to show how a candidate can move between business context and technical detail without losing the thread.

Candidate: “I led the backend work for a grant-review portal. Administrators were reconciling reviewer comments against changing application documents. My main decision was to make each submitted revision immutable and attach review assignments to that revision. I worked with a frontend engineer and a program administrator; I owned the schema and submission flow.”

Interviewer: “Why was an audit log insufficient?”

Candidate: “A log of field changes could preserve history, but our review screen needed a stable object that a reviewer could reopen. We considered reconstructing old state from changes. With our existing tooling, that increased read-path complexity and made missing changes difficult to detect. Complete revisions used more storage but made the referenced submission explicit.”

Interviewer: “What exactly was in the model?”

Candidate: “An application identified the applicant's continuing request. A submitted revision had its own ID, the application ID, a revision number, and a reference to the submitted content. A review assignment referred to a revision and reviewer. A review decision referred to its assignment. This let us distinguish the application from the particular content reviewed.”

Interviewer: “What happens if the applicant submits again during a review?”

Candidate: “Existing assignments still point to the old revision. The product decision was to show administrators that a newer revision existed, rather than silently moving a reviewer to different content. Administrators could initiate another review according to the program's rules. We deliberately kept that action explicit.”

Interviewer: “Did that solve the whole problem?”

Candidate: “It solved the ambiguous reference, but created a discoverability problem. In the pilot, an administrator missed the newer-revision indicator. We changed the review summary to state the reviewed revision and latest submitted revision together. That feedback changed the presentation, not the historical relationship.”

Notice what the candidate has not done: recite every service, attribute all work to themselves, or describe a design choice as inevitable. Each answer supplies enough detail for another engineer to challenge it.

Go One Level Deeper Than Your Favorite Diagram

A diagram can show relationships, but a follow-up often asks how those relationships survive a failure. Continue the grant example by selecting one concrete race: two submissions attempt to create the next revision at the same time.

Explain the invariant first. In this design, revision identifiers are unique, and the application cannot point to an uncommitted submitted revision. Then describe the transaction boundary and conflict handling your actual system used. If a uniqueness constraint rejected one competing write, explain what the caller received and how a retry avoided creating an unintended second submission.

For technical revision, PostgreSQL documents how unique and foreign-key constraints enforce specific data relationships. AWS explains idempotent API retries, including why repeated requests need an explicit notion of caller intent. These are supporting engineering references, not evidence of Ashby's stack or interview requirements.

You do not need to invent an elaborate distributed architecture to make the discussion technical. A single database transaction can be consequential if it protects the product's meaning. Conversely, saying “we used transactions” is too vague if you cannot identify which writes belonged together.

Prepare one failure-path walkthrough as well. For example, a submission succeeds but its notification fails. Does the submission remain valid? How is notification retried? What does the user see? Distinguish the committed product state from a secondary communication effect. Describe your real implementation and its limitations rather than borrowing a fashionable pattern you never used.

Finally, prepare one rejected simplification. Could the team have stored only the latest revision and exported PDFs for history? Explain the support burden or access requirement that made this unsuitable, if those were actual constraints. A useful trade-off answer makes the cost visible on both sides.

Talk About Outcomes Without Inventing Precision

Prepare evidence in three categories: measurements you can support, observations you directly witnessed, and things you do not know. These categories can coexist in a strong project story.

A measured claim needs a definition and comparison. If you say review handling became faster, identify what interval was measured, which users were included, and whether the before-and-after periods were comparable. A rollout observation is not automatically evidence that the feature caused a change in a business metric.

A qualitative outcome can still be concrete: “During the pilot, administrators could reopen the exact revision referenced by a decision. Two usability issues remained, and we changed the summary screen before expanding access.” That is more defensible than an invented percentage improvement.

For the fictional dialogue, a truthful continuation might be: “I do not remember the exact median handling time, so I would not quote it. I do remember the rollout stages and the mismatch we corrected. We did not run a controlled experiment, so I would avoid attributing the broader program's turnaround change entirely to this feature.”

Before the interview, review only materials you are entitled to access and disclose. Replace customer identities with neutral descriptions and omit confidential implementation details. If you normalize a metric or use an approximate scale, say so. The goal is a faithful account, not a disguised collection of unsupported numbers.

Prepare for a Conversation With Branches

Rehearse a short opening that establishes the user, problem, your responsibility, and the decision you want to examine. Then practice stopping. Ask a partner to interrupt with “why,” “what failed,” or “show me the data relationship” before you reach the outcome.

When interrupted, answer the question directly and reconnect the answer to the project. A useful return sentence is: “That constraint is why we kept old review assignments stable. The next issue was making that state clear to administrators.” You preserve continuity without insisting on finishing a memorized script.

If you do not recall a field name, distinguish forgotten syntax from forgotten design. You may remember that an assignment referenced a revision without remembering whether the column was called revision_id or submission_version_id. State the relationship accurately and acknowledge the naming uncertainty. If you do not remember the relationship itself, that is a substantive gap to prepare or admit.

Keep any visual aid small enough to navigate while speaking. For the grant example, one relationship diagram and one decision comparison would support most branches. A long deck can make it harder to answer an unexpected question because the evidence is scattered across slides.

Sources and Further Reading

• Ashby: Engineer Past Projects Deep Dive — official engineering interview preparation; page last updated July 25, 2025, checked September 2026.
• PostgreSQL: Constraints — technical reference for uniqueness and referential integrity.
• AWS Builders’ Library: Making retries safe with idempotent APIs — technical background for retry discussions.