Skip to content
Aethel

Prepare for an AI interview as a developer

Some companies now use an AI interviewer for the first conversation with developer candidates. This guide covers what those interviews ask, how answers tend to be judged, and how to practice for your role and level for free. Aethel runs one of these interviews, a free conversation of about 15 minutes about your own work. Where this page describes Aethel, it says so.

Practice for free Find your role's guide

What AI screening interviews ask developers

Formats differ by tool and by company. Before you start, read the candidate guide or ask the recruiter which of these you will get:

  • A conversation about your past work. The interviewer asks about a project, an incident or a decision, then follows up: why that way, what else you considered, how you knew it worked. Aethel's interview is this kind.
  • A coding exercise in the browser. You write or fix code in an editor, sometimes while explaining it. Ask which languages are allowed, whether you can run tests, and whether you may look things up.
  • A system design discussion. You describe how you would build something, out loud or on a shared whiteboard, and defend your choices when the interviewer changes the requirements.
  • Recorded answers to fixed questions. You see a question, get time to think, and record a reply. Nobody follows up, so each answer has to carry its own context and its own result.

Whatever the format, the questions for developers keep coming back to the same themes:

  • Something you built or owned, and what made it hard.
  • A bug, outage or failed release, from the first sign to the fix.
  • A trade-off between speed, reliability, cost and how easy the code is to change.
  • How a system or codebase changed as it grew.
  • Testing and code review when the deadline is close.
  • Explaining a technical risk to someone who is not an engineer.
  • Disagreeing with a teammate, a reviewer or a product manager.

Follow-up questions are where depth shows. A good AI interviewer keeps asking about the case you chose, so a story you half remember thins out by the second follow-up. Pick cases you know well enough to answer "why" three times.

How answers are judged

Each tool has its own rubric, and many do not publish theirs. Most look for the same signals any careful interviewer would:

  • A specific case. One project, one incident, one decision, with enough context to place it: the product, the scale, the size of the team.
  • Your own part. What you did, said with "I", kept apart from what the team did.
  • Reasoning. Why you chose it, what else you considered, and what risk you were guarding against.
  • A result someone could check. A number, a before and after, or the person who confirmed it.
  • Honest limits. What you did not know at the time, or what you would change now. It reads as judgment, not weakness.

What rarely helps: a list of languages and frameworks with no decision behind it, the team's results told as yours, and a textbook definition where the question asked about your experience.

Guides by developer role

Each guide has the questions AI screens ask that role, two worked examples, each with a weak and a strong answer and why, common mistakes, the numbers worth having ready, and a link to practice that role for free.

New to developer jobs? AI interview prep for junior developers, bootcamp grads and career changers covers what counts as experience when it is a bootcamp, school projects or another career.

How to practice in a week

  1. Choose three cases. An incident or bug you chased down, a design decision you made or argued for, and a time you worked through a disagreement or explained something hard. Recent cases are easier to tell in detail.
  2. Write a numbers sheet. For each case, note the numbers that place it: users or requests, data size, team size, latency, error rate, build time, crash rate. Rounded numbers are fine. Writing them down makes you find them before an interviewer asks.
  3. Write down the options you rejected. For each decision, name at least one alternative and why it lost. Most answers skip this part, and it is exactly where follow-up questions dig.
  4. Say each case out loud, twice. Tell it start to finish in about two minutes, then again in one. Notice where you say "we" when you mean "I", and where the result goes vague.
  5. Practice your track and level for free. Pick your role and level on the practice page and type an answer to each question. After each answer, a quick check in your browser quotes your own words back for each habit (a real example, your own part, why you chose, how it turned out) and suggests one thing to try. It is not a score.
  6. Prepare one explanation for a non-engineer. Take a technical risk from one of your cases and explain it in three sentences to someone in sales or support. Developer interviews often ask for this, and it is hard to improvise.
  7. Check the setup the day before. Read what the tool needs: browser, microphone, camera, screen sharing, quiet room. For Aethel's interview, a camera is not required and you can type every answer.

What changes with your level

Junior

Questions stay close to code you wrote: a feature, a bug, a test you added, something a code review taught you. Internships, coursework, hackathons and open source all count. Scale still matters, so say how many users or how big the codebase was, even when it was small.

Practice junior questions

Bootcamp, school or a career change: read the junior guide.

Mid-level

Expect questions about owning one part of a system end to end: a service, a screen flow, a pipeline. Interviewers listen for trade-offs you weighed yourself, and for how you knew the result held up after release.

Practice mid-level questions

Senior

Questions move to decisions that crossed teams: a migration, an architecture change, a standard you set, a person you mentored. Interviewers listen for risk, sequencing, and results followed for months rather than days.

Practice senior questions

Before the interview, ask these

A two-minute email to the recruiter, or a read of the tool's candidate guide, answers most of the surprises:

  • Is there code to write, and in which languages?
  • Is the interview recorded, and who sees the recording or the transcript?
  • Will I see my own results, or only hear back from the company?
  • Can I type instead of speaking, or ask for more time?
  • What happens if my connection drops halfway through?
  • Can I retake it, and does the company see how many attempts I took?

For Aethel's interview, the answers are public: no code to write, a written transcript instead of a recording, your results shown to you first, typing allowed for every answer, and the rest in the interview guide. See how the Aethel interview works and your rights as a candidate.

Questions developers ask

Do AI interviews for developers include live coding?

Some do and some do not. Ask the company or read the tool's candidate guide before the day. Aethel's interview has no code editor: it is a conversation about your own work, answered by speaking or typing.

Can I use ChatGPT or another AI assistant during an AI interview?

Follow the tool's rules, and when they say nothing, ask. Some tools forbid it, and an answer you did not write rarely survives a follow-up about your own project. Aethel's rule is: "Answer in your own words. Notes are fine. Do not paste answers written by ChatGPT or another AI." Each answer is marked spoken, typed, or pasted, and a company that sees your result sees that mark. Assistants are more useful before the interview, to quiz you on your cases.

How long should each answer be?

Long enough to tell one case in order: the situation, what you did and why, and the result. Spoken, that is often one to two minutes. In Aethel's rules, a reply under 8 words is not an answer, and an area scores 90 or more only when one of its quotes is complete and at least 20 words long.

I am a junior developer without production experience. What can I talk about?

An internship, a coursework project with real users or real data, an open-source pull request that went through review, a hackathon, or a bug you tracked down in your own app. Give it the same shape as any case: where it was and how big, what you did, why, and how it turned out.

Do I have to name my employer or share code?

No. Say "a payments startup with about 40 engineers" instead of the name, round the numbers, and leave out secrets, credentials and code you are not allowed to share. The decision and the reasoning carry the answer, not the company name.

Is the free practice the same as the real interview?

No. The practice page shows a few questions for your track and level on screen, you type your answers, and each one gets a quick rule-based check in your browser. It is not a score, it needs no account, and nothing is saved. A real interview follows up on what you say.

Will my accent or imperfect English count against me?

That depends on the tool, so ask. In Aethel's interview, only the text of your answers is scored, never your voice, accent, grammar or fluency, and you can type instead of speaking. You can also take Aethel's interview in Spanish.

More to read

En español: cómo prepararse para una entrevista técnica con IA.

Ready to try it?

Practice your role's questions first, then take the free Aethel interview when you are ready. Neither needs a card.

Practice for freeTake the free interview