Demo persona

Diego Alvarez — Former teacher turned self-taught / bootcamp developer

Taught high-school math for eight years, then retrained through a coding bootcamp and self-study. Building small web projects and looking for a first junior developer role.

  • Goal Assess fitness for a specific role
  • Role context An actual job description
  • Interview style Structured HR interview

Diego completed a structured, roughly 35-turn interview about how he learns, builds, and works with people — measured against a real Junior Frontend Developer job description.

Choose whether to open the saved sample immediately or run the current Railway inference stack over this persona's transcript and documents.

Uses the live models. The first run can take several minutes.
View saved sample Instant precomputed report for presentation use.

Evidence this persona provided

Copy-pastable — drop these into the normal chat / analyze flow if you want to run the pipeline yourself.

Cover letter

Portfolio

Target role context (An actual job description)

This is the "assess fitness for a specific role" input — it feeds the CCI's Task-Entropy grounding and role-fit read.

Simulated interview transcript (70 turns)
Thanks for coming in, Diego. I'd like to go through this methodically. Let's start with the big move — why did you leave teaching to code?
I loved teaching but hit a ceiling, and I kept being curious about how the software I used every day actually worked. Rather than stay comfortable and restless, I chose to become a beginner again. Leaving a stable job was scary, but staying bored scared me more.
How did you actually go about learning to code?
The bootcamp gave me a map, but the real learning came after, building things alone and breaking them. I don't feel I understand something until I've broken it and fixed it myself. Copying a tutorial teaches me nothing; wrestling with my own bug teaches me everything.
Tell me about the most substantial thing you've built.
A small React app to help my old students practice math problems. It tracks what they get wrong and drills those. It's not fancy, but I built it end to end — I owned every part, from the UI to the logic, with nobody to hand the hard bits to.
Was there a point where you had to significantly redo it?
Yes. My first version had state scattered everywhere and it became a tangle. Once I actually understood React's model, I rewrote the whole state logic. It was humbling to throw away working code, but the rewrite made everything after it easier.
Why rewrite rather than patch it?
Because I could feel every new feature getting harder to add — that's the smell of a bad foundation. Patching would've bought a week and cost a month. I'd rather pay the honest cost of doing it right once I finally understood the right way.
How does teaching connect to being a developer, in your view?
They're the same core skill: making something abstract and confusing become clear. For eight years I broke hard ideas into steps for thirty different minds. Debugging is that instinct aimed at a machine — form a hypothesis, test it, don't stop until you truly understand the cause.
Walk me through how you debug something you don't understand.
I resist the urge to randomly change things until it works, which teaches you nothing. Instead I form a specific guess about what's wrong, test just that, and narrow it down. It's exactly how I'd diagnose why a student kept making the same mistake.
Give me a real example of a bug that stumped you.
A component kept re-rendering and I couldn't see why. I assumed it was my data fetching, but by isolating pieces one at a time I found it was a function I recreated every render. The lesson was to trust the method over my first assumption.
What did that teach you beyond the specific fix?
That my confident first guess is often wrong, and that's fine — the process protects me. I stopped being embarrassed about not knowing and started trusting that if I isolate variables patiently, I'll always find it. Patience beats cleverness in debugging.
The role involves code review. How do you take feedback on your work?
Genuinely well — as a teacher I gave feedback all day and know it's about the work, not the person. I want the harsh review that makes me better, not polite silence. I'll ask 'why' behind a comment so I learn the principle, not just make the one change.
And how do you give feedback, since you help others in your study group?
I try to lead people to the answer rather than hand it over, the same way I taught. When a peer's stuck, I ask questions that get them to spot the bug themselves. They learn far more, and they build the confidence to do it alone next time.
This is a junior role — how do you feel about not being the expert?
Comfortable. I deliberately gave up expertise to start over, so I've made peace with being the least experienced person in the room. I know how to ask good questions and how to be coached. That beginner humility is honestly one of my strengths right now.
How do you make sure you ask good questions rather than annoying ones?
I do my homework first — I try to solve it, write down what I tried, and then ask a specific question with that context. I'd never ask a senior something a five-minute search answers. Respecting their time by coming prepared is how I'd want a student to come to me.
What kind of environment helps you thrive?
One where it's safe to not know things and asking questions is normal. I learn fastest around people who explain their reasoning and don't shame beginners. A team that treats questions as a good sign rather than a weakness would get the best version of me.
And what would hold you back?
A culture where people hoard knowledge or make you feel stupid for asking. I saw the same thing kill curiosity in classrooms. If asking a question feels dangerous, people stop learning, and I'd be miserable and slow in that kind of place.
How do you handle being stuck for a long time on your own?
I set myself a timebox — struggle hard for a set period, because that's where learning happens, then ask for help rather than burning a whole day out of pride. Teaching taught me that productive struggle is good but suffering in silence just wastes time.
What do you do when you finish a task faster than expected?
I use the slack to understand the surrounding code better or write the test I skipped, rather than just grabbing the next ticket. As a beginner, every bit of extra context compounds. I'd rather deepen my footing than rack up rushed, shallow work.
How organized are you in how you work?
Quite — eight years of lesson planning wired that in. I break a task into small steps, keep notes on what I've tried, and commit in small logical chunks. Managing a classroom of thirty teaches you to stay organized or drown, and that habit came with me.
Tell me about a time you failed at something and what you did.
My first coding project I abandoned because I'd bitten off way too much with no fundamentals. Instead of pretending it was fine, I admitted I'd skipped the basics, went back and learned them properly, then rebuilt smaller. Failing early made me respect the foundations.
How do you keep yourself motivated over the long haul of learning?
I set concrete, shippable goals — a small working feature, not a vague 'get better'. Finishing something real keeps me going. And I remember that I chose this hard path on purpose, which makes the frustration feel like progress rather than punishment.
How would you contribute to a team beyond just your code?
I'd help make knowledge stick — writing clear docs, explaining tricky things to the next new person, keeping onboarding humane. That's the teacher in me. A team is stronger when understanding is shared, and spreading understanding is literally what I'm best at.
Where do you think AI fits into a junior developer's work?
It's a fast tutor and a code generator, and I use it to explain concepts and speed up boilerplate. But it'll confidently give wrong answers, so I treat it like a clever student who needs checking. It accelerates my learning; it doesn't replace understanding it.
Doesn't relying on it risk you never really learning?
That's the real trap, and I'm deliberate about it. If AI writes something I don't understand, I make myself explain it back line by line before I use it. I use it to learn faster, not to skip learning. The understanding has to actually be mine.
How do you see your value holding up as these tools get better?
By being someone who genuinely understands the fundamentals and can judge whether generated code is right, plus communicate well on a team. The people who only paste and pray will struggle. I'm betting on real understanding and being easy to work with.
How do you structure your time between learning and actually building?
I learn just enough to start, then build, because I retain things far better when I'm applying them to a real problem. I keep a running list of concepts I hit and don't fully understand, and I circle back to those deliberately rather than trying to learn everything up front.
How do you handle feeling overwhelmed by how much you don't know?
I remind myself that overwhelm just means I'm looking at the whole mountain instead of the next step. Teaching taught me that — you don't give a student the whole curriculum at once. I shrink it to 'what do I need for this one task' and the panic goes away.
Tell me about a time you had to admit you couldn't do something.
In my study group I confidently offered to help someone with a backend problem, then realized I was out of my depth. I stopped and said 'I actually don't know this well enough to guide you — let's find out together'. Faking it would've taught them something wrong.
Do you struggle with impostor syndrome as a career-switcher?
Sometimes, especially seeing people who've coded since they were twelve. But I reframe it: I bring eight years of managing people, explaining hard things, and staying calm in chaos that they don't have. I'm not behind, I'm differently equipped. The nerves are just the cost of growing.
Tell me about a time you took initiative nobody asked for.
In my study group, people kept getting stuck at the same setup step, so unprompted I wrote a clear little guide and walked newcomers through it. Nobody assigned me that. It's the teacher reflex — I see people tripping on the same thing and I have to smooth the path.
What do people misunderstand about you?
That switching careers late means I'm a risky or desperate hire. Actually it means I chose this deliberately and I'm hungry in a way a default-path grad often isn't. I gave up a stable job because I want this. That's not desperation, it's commitment.
Is there a value you won't compromise on?
Not pretending to understand something I don't. In teaching, faking knowledge in front of students is how you lose them and teach them errors. Same in code — I'd rather say 'I don't get this yet' and learn it properly than ship something I can't actually explain.
What does great collaboration feel like to you?
When people explain their reasoning openly and it's safe to ask anything, so everyone levels up together. My best study-group sessions felt like a good classroom — no ego, lots of 'oh, that's why'. A team where senior people teach as they go is where I'd flourish.
How do you handle the boring or repetitive parts of the work?
I look for the pattern and try to automate or template it, which is also a way to learn. Grading a hundred tests taught me to build systems for repetition. If something's tedious and recurring, that's usually a sign there's a tool or a script waiting to be written.
What skill are you deliberately building right now?
Reading other people's large codebases, which is very different from writing my own small projects. Real jobs are mostly understanding existing code, so I've started contributing tiny fixes to open-source projects just to practice navigating unfamiliar code I didn't write. It's humbling and exactly the gap I need to close.
Final question: if you got this junior role and it went well over two years, what would be true?
I'd be a solid, trusted contributor shipping real features, no longer needing hand-holding but still asking sharp questions. I'd probably be the one helping the next newcomer feel safe. And I'd have proven that a teacher who chose to start over can compound into a real engineer.