AI interview prep for junior developers, bootcamp grads and career changers
An AI screening interview asks about your experience, and when that experience is a bootcamp, a degree, side projects or another career, it is easy to freeze or to start with an apology. You do not need a developer job title to give a strong answer. You need one real case, told with its context, your own part, your reasoning and how it turned out. This guide covers what counts as experience, what AI screens ask junior developers, two worked answers, how to use a previous career as evidence, and free practice at the junior level.
En español: Entrevista con IA para desarrolladores junior, de bootcamp o en cambio de carrera
Who this guide is for
- Bootcamp graduates looking for a first developer job.
- Students and new graduates whose experience is coursework, an internship or a thesis.
- Self-taught developers with side projects, freelance work or open source contributions.
- Career changers: teachers, nurses, accountants, warehouse, retail and support staff, anyone moving into software with real work behind them.
- Developers in their first two years, applying for a junior or a first mid-level role.
What counts as experience
An interviewer needs a case they can place and follow up on. All of these qualify when you tell them with the same shape as any work story: where it was and how big, what you did, why, and how it turned out.
- A team project from a bootcamp or a course. Say how many people, how long, which part was yours, and one decision you made. Most of the value is in the part you owned.
- Something real for a real person. A site for a family business, a sign-up form for a club, a small tool for a teacher. Real users, even 12 of them, give you results to report.
- Open source. A pull request that went through review, even a small one, shows you can read someone else's code and act on feedback.
- An internship or an apprenticeship. Even a few weeks gives you a codebase, a team and a reviewer. Say what you changed and what the review taught you.
- Your own app or tool. A project you deployed and kept running counts for more than one that only ever ran on your laptop. Say who used it and what broke.
- Automation in a previous job. A script, a spreadsheet or a small tool that saved your team time is real engineering work, with a before and an after.
A tutorial project you followed step by step is the weakest source. If it is all you have, talk about what you changed or added beyond the tutorial, and why.
What AI screens ask junior developers
A project you are proud of
“Tell me about a project you built. What was your part, and what was the hardest part?”
Listening for: One project, your own part said with "I", one hard problem, and how you knew it worked.
A bug that stopped you
“Describe a bug you were stuck on. How did you get unstuck?”
Listening for: How you narrowed it down, what you tried that did not work, who or what you asked, and the cause in one sentence.
Learning something fast
“Tell me about a time you had to learn a new tool or language quickly.”
Listening for: What you needed it for, how you learned it (the docs, a small experiment, a person), and the deadline you met or missed.
Feedback you received
“What is a piece of feedback on your code that changed how you work?”
Listening for: The actual comment, why it was right or partly right, and what you have done differently since.
Working in a team
“Tell me about a disagreement in a group project and how it was settled.”
Listening for: A real disagreement about the work, both positions, and what you did, rather than who was wrong.
Your path into software
“What did you do before, and what from it helps you as a developer?”
Listening for: A specific skill or habit from your earlier work, shown with a case instead of a list of strengths.
Something you do not know yet
“How would you approach a task in a part of the stack you have never used?”
Listening for: A plan with a small first step, how you would check your work, and when you would ask for help.
Worked example: a bootcamp capstone with a real customer
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.
Question: “Tell me about a project you built. What was your part, and what was the hardest part?”
Weak answer
“For my bootcamp final project, my team built a full-stack web app for a restaurant. We used React, Node and MongoDB. I worked on a lot of different parts, the front end and some of the back end. It was challenging but we learned a lot, and we presented it on demo day and got good feedback.”
Why it is weak: There is a project, but no part of it is clearly yours, nothing says what was hard, and "learned a lot" and "good feedback" are not results. The interviewer has to guess what you can do, and the next question, "which part did you build?", starts from zero.
With Aethel's rules: Situation 1, reasoning 0, result 0: 1 of 8 points, and with no specific case the area is at most 60 on Aethel's scale.
Strong answer
“For my bootcamp capstone, four of us built online ordering for a family taco shop near my apartment, which took about 30 phone orders on a Friday night. I owned the order flow: the menu page, the cart and the API that saved orders. The hardest part was that the owner changed prices and marked dishes sold out from her phone during service, and in our first test two customers ordered a dish that had already run out. I made the server check every item's price and availability when the order was placed, instead of trusting what the cart showed, and return a clear message listing the items that had changed. I considered refreshing the menu on the page every few seconds instead, but that still left a gap of a few seconds, and it would have kept reloading the menu on every customer's phone. I wrote 14 tests for the order rules. In the three weeks before demo day the shop took 112 orders online, none for a sold-out dish, and the owner still uses it on weekends.”
Why it is strong: It gives the team size in one sentence and spends the rest on the part that was yours. The hard problem comes from a real user, the fix is one clear decision with the alternative it beat, and the result is real use, small but checkable, plus tests that guard the rule.
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 happens if two customers order the last portion at the same moment? Saying how the order and the stock change together, in one step, is a strong junior answer.
Worked example: a warehouse supervisor who fixed picking errors
Question: “What did you do before, and what from it helps you as a developer?”
Weak answer
“Before coding I worked in logistics for six years. I have always loved technology, so I decided to make a change. My previous job taught me a lot about teamwork, communication and working under pressure, which I think are really important skills for a developer.”
Why it is weak: Teamwork, communication and pressure are claims every candidate can make, with no case behind them. Six years of real work go unused, and the interviewer learns why you like technology but not what you can do.
With Aethel's rules: Situation 0, reasoning 0, result 0: 0 of 8 points, and with no specific case the area is at most 60 on Aethel's scale.
Strong answer
“For six years I supervised the night shift at a distribution warehouse, about 25 people and 4,000 orders a night. Our biggest cost was picking errors, wrong items sent to stores, on about 2 percent of order lines. I exported a month of error reports and found that most errors came from 30 products with near-identical labels stored next to each other. I could not change the warehouse software, so I built a spreadsheet that flagged look-alike products in neighboring slots, and moved them apart with the day manager's approval. Retraining everyone was the other option, but the people were not the problem, the layout was. Errors fell to about 0.6 percent over the next two months, and the other two shifts adopted the sheet. That project is why I went to a bootcamp. I use the same habit in code: I look for the pattern in the data before I change anything, and I check the number afterwards.”
Why it is strong: It treats the old job as a real case: the size, a measured problem, a diagnosis from data, a constraint, an alternative weighed and a result adopted beyond the case. The last two sentences connect it to software in one honest line, without renaming warehouse work as engineering.
With Aethel's rules: Situation 2, reasoning 2, result 3: 7 of 8 points, which is 91 on Aethel's fixed scale. A real score can differ.
What comes next: Expect: what would you build for that warehouse now that you can code? Naming the small tool or report, and how you would test it, links the two careers.
Using a previous career as evidence
If you worked before you learned to code, you already have cases an interviewer can use. Look for these in your old job:
- A process you made faster or safer. A checklist, a template, a schedule or a spreadsheet that cut errors or time. It takes the same judgment as a code change, and it has a before and an after.
- A problem you diagnosed. Finding out why stock counts were wrong, why a report did not add up, or why a shift handoff kept losing information is debugging.
- Explaining something hard. Teaching a class, training a new hire or explaining a bill to an upset customer is close to explaining a technical risk to someone outside engineering.
- Working under pressure with rules. Shifts, deadlines, audits and safety rules are close to releases and on-call. Say what you did when something went wrong.
Keep it honest: describe what you did in that job in that job's own terms, then say in one sentence how it shows up in your work as a developer. Do not rename your old work as software work.
Common mistakes in junior answers
- Opening with an apology. "I do not have real experience, but..." tells the interviewer to discount whatever comes next. Start with the case.
- Telling a tutorial as your own design. If you followed a course, say so, then talk about the part you changed. A follow-up question will find the difference anyway.
- "We" all the way through. In a group project the interviewer wants your part. Say "I" for what you did, and name what teammates did.
- Listing what you learned. "I learned React, Node, SQL and Git" is a syllabus, not an answer. Pick one thing and show it working in a project.
- Hiding your previous career. Ten years as a teacher or a nurse is not a gap to explain away. It is often where your best evidence of judgment and communication lives.
- Inflating the numbers. Small numbers are fine: 12 testers, 40 orders a week, 3 teammates. A made-up scale falls apart at the first follow-up.
Numbers worth having ready, even small ones
- How many people used what you built, even if it was 12 classmates or one shop
- How long the project took, and how many people worked on it
- Tests you wrote, bugs you closed, or pull requests that were merged
- Time or errors saved by a tool or a change, before and after
- The size of the data: rows, products, records or files
- From a previous job: the people, shifts, orders, students or budget you were responsible for
Practice at the junior level, free
The practice page has a junior level for every developer track, meant for up to 2 years of experience, a bootcamp or a career change. Pick your track, 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 junior developers and career changers
Is a bootcamp project real experience?
For a junior role, yes, when you tell it as a case: the project, the team, your part, a decision and how it turned out. Say that it was a bootcamp project. What weakens it is vagueness, not where it happened.
Should I mention my previous career in a developer interview?
Yes, briefly and with a case. One story from your old job that shows how you solve problems or explain things is often stronger evidence than a second coding project.
My project was a team effort. How do I talk about it without taking credit?
Give the team size and what the others did in one sentence, then spend the answer on your part. "Four of us built it; I owned the order flow and the API behind it" is honest and specific.
My project never had real users. What do I say for results?
Use what you can check: tests that pass, a page that loads in under a second, a bug that no longer happens, a reviewer's comment. Say plainly that it never had real users, and what you would measure if it did.
Can I take Aethel's interview without a developer job?
Yes. Aethel's interview is free, takes about 15 minutes, and asks about your own work, which can be projects, coursework or a previous career. Its published scoring rules rate the case you describe (the situation, your reasoning and the result) on one scale that is the same for everyone, and a reply under 8 words is not counted as an answer.