For a long time, the interview question worked. You’d ask someone to write a function and watch them do it. This showed you something real: whether they understood the language, could keep the problem in mind, and whether they had real experience or were just pretending.
That question doesn’t work anymore. Now, even someone who just learned a language two weeks ago can write clean, working code. The code itself tells you almost nothing about the person who wrote it. So we ended up with an interview process that measured a skill we no longer needed, while the things we actually care about went untested.
So we changed our approach. But before I explain how, it’s important to be honest about what really changed.
Coding is not something you practice by accident anymore
It used to happen naturally. You wrote code every day because that was the only way to get things done, and after thousands of hours, you became fluent without even trying. Practice was what taught you.
That’s changed. Now, most days, the code is ready before you even finish explaining what you want. You read it, tweak it, and send it off, but you don’t build the same skills you did by writing it yourself.
People often compare this to calculators, and it’s a good analogy. Before calculators, being able to do math quickly in your head was a real job skill, not just a neat trick. When calculators arrived, people stopped practicing mental math. No one really missed it. Instead, the important skill became knowing which numbers to enter and checking if the answer made sense.
The panic isn’t new
If you scroll through social media, you’ll see old articles from the 1950s and 60s warning that automation would end technical jobs. The tone is just like today’s headlines, with the same level of certainty.
But after that, tech jobs actually grew more than ever, thanks to computers and automation. The machines that were supposed to end the work ended up creating decades of new jobs instead.
But plenty of engineers really did get replaced
But there’s a part people often leave out when they use this story to reassure others. While the total number of jobs increased, some people still lost their jobs, including engineers, and it wasn’t just by chance.
Think about who disappeared:
- The one who plugged values into an equation somebody else had derived, generated the report, and called it a day. Never asked whether the equation was still the right one. Never looked for a faster way to get the number. A spreadsheet does that job now, and it doesn’t need a lunch break.
- The one who spent three days drawing a design in pencil while CAD software sat unused nearby. It wasn’t that the pencil drawing was better; it just felt more familiar. Meanwhile, the engineer who learned to use CAD could try out six design ideas before lunch and actually see which one worked best.
- The one whose job was running the same checklist by hand every release cycle and typing up what happened. Valuable work, genuinely. Also work that gets automated the moment someone bothers to write it down properly. The person who did the writing-down stayed.
- The one whose value was knowing where things were, which handbook, which page, which table had the right number. That kind of expertise took years to build. Now, search engines can find it in two seconds, so being the person who remembered stopped mattering.
Four different roles. One pattern underneath all of them.
The pattern: machines take the settled part
All of those jobs had already been worked out. The method was clear, the steps were known, and people were there just to follow them correctly. Machines are designed to take over tasks that require accuracy in a set process.
What remained for people were the tasks before and after the routine work: deciding which problems to solve, choosing how to solve them, and judging if the results were correct. The engineers who kept their jobs were already doing these things, using new tools to do even more, and doing it faster.
That hasn’t changed. The difference is that now it’s happening to us.
The prompt test
If you want a rough way to check where you stand right now, try this one: could someone write out everything you do at work as a prompt?
Not just a vague summary, but every detail: every input, every decision, every step, every check. If a manager could describe your work so completely that a model could do it, there’s a good chance you could be replaced. Maybe not this year, but the trend is clear.
The real value of that test isn’t to scare you. It’s the lesson inside it. Focus on building skills and gaining experience that can’t be turned into a simple prompt: knowing which problems matter, noticing when a confident answer is wrong, understanding systems well enough to predict failures, and turning unclear requirements into clear ones. None of that fits in a text box.
There’s no version of this where you learn it once
It would be nice if you could just adjust once and relax, but that’s not possible. The tools are improving quickly, and the line between what they can do and what still needs a person keeps shifting. Wherever you draw that line today, it will move by next year.
So treat this as an ongoing habit, not a project with an end date. Keep using new tools. Keep noticing what they can’t do yet. Keep pushing your own work to the edge of what’s possible.
What this changed about how we hire
At Fcode Labs, this is the kind of person we’re trying to find, so we reworked the junior hiring process to actually look for them.
The old format measured something else: could you remember the solution and type it out? That doesn’t work anymore. Now, a candidate is more like an editor, a verifier, and a director of generated code, not just the sole author. That’s what we look for now.
There’s also a risk factor that made this urgent, not just interesting. A weak junior used to be slow. Now, a weak junior with AI is fast but often wrong, creating believable code faster than a reviewer can spot the mistakes. Being able to verify code isn’t optional anymore.
In broad strokes, what we look for:
- Verification instinct: the reflex to ask “how do I know this is actually true?” before acting on any answer, whoever or whatever gave it.
- Decomposition: breaking a fuzzy goal into concrete, checkable pieces before touching a tool. Point AI at a well-defined problem and it’s superb. Point it at mush and you get confident mush at scale.
- Mental model depth: understanding why systems behave the way they do, because you can’t catch a plausible wrong answer without your own model to check it against.
- Learning velocity: how fast someone goes from zero context to correct, testable progress on something unfamiliar.
- Calibrated honesty: saying “I’ve read about this” instead of “I’ve used this,” flagging the parts they’re unsure of, updating without getting defensive.
We also stopped doing a few things. We no longer test closed-book syntax recall or use puzzle problems that any assistant can solve in seconds. We don’t ban AI in interviews anymore, since that just bans the real job and rewards people who hide their process. Instead, we give candidates the tools, watch how they use them, and ask which parts of the output they didn’t trust.
The full breakdown is more than fits here. I’m writing that up separately.
Every tool we’ve ever built took over the part of the work we’d already figured out. The rest, the part nobody has figured out yet, has always been the job. It still is.
