Skip to content
Aethel

AI interview prep for full-stack developers

Full-stack interviews ask whether you can carry a feature from the database to the button and keep it working after release. An AI screen will probe the seams: where logic should live, what happens when the API and the screen disagree, and how you decided what to build first. Here are the questions to expect, two worked answers, and the mistakes that make full-stack answers sound thin.

Practice full-stack questions free

Entrevista con IA para desarrolladores full-stack: esta guía en español

What AI screens ask full-stack developers

  1. A feature you shipped end to end

    “Walk me through a feature you built across the front end and the back end. What were the hardest decisions?”

    Listening for: Decisions at each layer, not a list of layers: the data model, the shape of the API, the screen states, and how they fit together.

  2. Where logic lives

    “Tell me about a time you had to decide whether logic belonged in the client or on the server.”

    Listening for: Security, consistency and speed weighed against each other in a real case.

  3. A schema change that reached the UI

    “Describe a data model change that rippled into the interface. How did you keep older clients working?”

    Listening for: Versioning, backward compatibility, and how long the old path had to live.

  4. Debugging across layers

    “A user reported wrong data on screen. How did you find which layer was at fault?”

    Listening for: A method: reproduce, follow the request, check each boundary, and the cause in one sentence.

  5. Scope under a deadline

    “You had two weeks for a feature that needed four. What did you cut?”

    Listening for: What users needed first, what you deferred, and how you told the product manager.

  6. Owning it after launch

    “After launch, how did you know the feature was working?”

    Listening for: Logs, metrics or analytics you set up yourself, and one thing they showed you.

  7. Working with specialists

    “How did you work with a backend or design specialist who disagreed with you?”

    Listening for: A real disagreement, what you learned from it, and how it was settled.

Worked example: online booking for a clinic chain

Each example shows a weak and a strong answer to the same question. The “With Aethel's rules” lines apply Aethel's published scoring rules, one concrete example of how an AI interview can judge an answer.

Made-up exampleWritten by Aethel to show the difference. Not a real candidate, and not scored by the AI.

Question: “Walk me through a feature you built across the front end and the back end.”

Weak answer

“I built a whole booking feature by myself, front end and back end. I made the React components, wrote the API in Node, set up the database tables and deployed it. It was a lot of work but it came out really well and the client was happy.”

Why it is weak: It lists layers instead of decisions. Nothing says what was hard, what was chosen over what, or how anyone knew it worked. "The client was happy" is a feeling, not a result, and "by myself" invites a follow-up the answer cannot support.

With Aethel's rules: Situation 1, reasoning 0, result 1: 2 of 8 points, and with no specific case the area is at most 60 on Aethel's scale.

Strong answer

“At a physiotherapy clinic chain with 12 locations, I built online booking so patients could pick a therapist and a time instead of phoning. The hard part was double booking, because front desk staff kept booking phone patients in the same calendar. I made the database the only judge of availability, with a unique constraint on therapist and start time, and the booking API returns a clear conflict when the slot is gone, which the screen turns into "that time was just taken" with the next three free times. I considered holding a slot for five minutes while the patient filled in the form, but most patients finished in under a minute, and holds would have blocked phone bookings at the busiest hours. I also logged an analytics event for every conflict. In the first three months about 2,100 appointments were booked online, calls to the front desks fell by roughly a quarter according to the clinics' phone reports, and conflicts stayed under 1 percent of attempts.”

Why it is strong: It names the business, the size and the user problem, then spends the answer on one hard decision that crosses every layer: a database constraint, an API response and a screen message designed together. A rejected alternative comes with its cost, and the result is measured, partly by someone outside the team.

With Aethel's rules: Situation 2, reasoning 2, result 2: 6 of 8 points, which is 87 on Aethel's fixed scale. A real score can differ.

What comes next: Expect: how did the front desk system learn about online bookings? Say whether both used one table or one synced to the other, and what happened when a sync failed.

Worked example: cutting scope before a trade show

Made-up exampleWritten by Aethel to show the difference. Not a real candidate, and not scored by the AI.

Question: “You had two weeks for a feature that needed four. What did you cut?”

Weak answer

“That happens a lot. I usually talk to the product manager and we figure out what is most important. Then I focus on the core features and leave the nice-to-haves for later. Communication is key in those situations.”

Why it is weak: This is a habit described in general, so there is no feature, no cut and no consequence. The interviewer learns that you talk to product managers, which almost everyone says.

With Aethel's rules: Situation 0, reasoning 1, result 0: 1 of 8 points, and with no specific case the area is at most 60 on Aethel's scale.

Strong answer

“At a 25-person company selling scheduling software to gyms, I had two weeks before a trade show to ship class waitlists, which the design covered with automatic promotion, email and text notices, and a staff override screen. I listed what a gym needed on day one: a member joins the waitlist and gets the spot when someone cancels. I kept automatic promotion and email, and cut text messages, the override screen and waitlist reports. For overrides I gave staff a temporary action on the existing member page, which took a day instead of a week. I wrote each cut in the ticket with its reason and a target date, walked our product manager through them, and she agreed to show the feature as a beta. We shipped on time, 31 gyms turned waitlists on in the first month, and text messages came in the next release after four gyms asked for them, which gave us a real signal instead of a guess.”

Why it is strong: The cut list is concrete, and each cut has a reason tied to what a gym needed on day one. A cheaper stand-in replaces the deferred screen, the product manager is part of the story, and the outcome shows that deferring text messages was the right call.

With Aethel's rules: Situation 2, reasoning 2, result 2: 6 of 8 points, which is 87 on Aethel's fixed scale. A real score can differ.

What comes next: Expect: what did the temporary action cost you later? Saying when it was replaced, or why it never needed to be, closes the loop.

Common mistakes in full-stack answers

  • Listing the stack. "React, Node, Postgres, a cloud provider" is your resume, not an answer. The interviewer wants the decision at the seam between two of them.
  • Claiming everything. Full-stack candidates often say "I built it all". If a teammate did the infrastructure, say so. It makes the parts you did own more believable.
  • Skipping the unhappy paths. Loading, empty, error and conflict states are where full-stack features break. Mention how yours handled them.
  • Trusting the browser. If a price, a permission or an availability check lives only in the client, expect a follow-up about trust. Say where the real check happens.
  • No life after launch. A feature you shipped and never measured is half a story. Name the log, metric or user report that told you it worked.
  • Depth nowhere. Breadth is the point of the role, but go deep on one layer per answer. Your breadth shows over the whole interview.

Numbers worth having ready

An interviewer places a case by its numbers. Find these for each of your cases before a full-stack interview; rounded is fine:

  • Users or accounts using the feature in its first weeks
  • Time from first commit to release, and how many people worked on it
  • Latency and error rate for the endpoints the feature added
  • Row counts or data size for the tables you changed
  • Conversion, support tickets or manual work the feature removed
  • How often the unhappy paths happened after launch: conflicts, failed payments, retries

Practice full-stack questions free

Pick a level, type an answer to each question, and read the quick check after each one. Free, no account, nothing saved, and not a score.

Questions from full-stack developers

Will the AI interviewer ask about front end or back end?

Usually both, often in the same question. If you lean one way, say so early, and choose cases where you made decisions on both sides of the API.

How do I show depth when my job is breadth?

Choose one decision per answer and follow it all the way down: why that column type, why that status code, why that message on screen. One deep path shows more than four shallow ones.

I work at a small startup and do everything. How do I describe scale?

Small is fine when it is specific: 3 engineers, 800 paying customers, 40,000 requests a day. What weakens an answer is having no numbers, not having small ones.

Should I talk about operations work as a full-stack developer?

If you set up the pipeline, the database backups or the alerts for your own feature, yes. Owning a feature in production is part of the role. Keep it to what you did yourself.

More developer guides

Start from the developer guide, Prepare for an AI interview as a developer, or read what Aethel's software engineering interview covers.