Just wrapped up junior interviews. Out of hundreds of resumes, we screened it down to three people. Candidate 1 literally shared his screen by accident and leaked a massive AI cheating setup. Candidates 2 and 3 padded their resumes to hell, basically implying they built core systems at big tech, but froze when we asked for a basic three-line python function with no tools. We rejected all three. 100% the right call. I’m not defending cheating, and if you lie or can’t even explain what your code is doing, you shouldn’t get the job. But there was a comment on a thread here the other day that ican’t shake: 'Yet those 3 people were the ones who got the interview, not the honest ones with non-embellished resumes. It really shows how broken the screening process is. we basically reward people who are good at exaggerating metrics, stacking keywords, and writing fake stories. we filter out the honest kid who built a normal CRUD app. Then, we bring the bullshitters in and try to punish them by taking away their tools and making them write syntax on a whiteboard. we are spotting the frauds, but we’re doing it using an outdated model of what a dev actually does. If we’re being real, we need to separate ‘cannot write syntax from memory’ from ‘cannot validate software behavior’. if a junior forgets how to merge two dicts in Python and has to ask an LLM, I seriously don’t care. But if the AI generates a payload merge that overwrites an is_admin permission key, and they blindly push it without checking auth or writing a test… that is a fatal lack of engineering ability. The syntax memory issue doesn’t matter, but not being able to audit the code is what kills production. Maturity in 2026 isn’t pretending Claude or local models don’t exist. It’s about control. A mature candidate is honest about using tools. Before writing code, they take a vague prompt and ask about user constraints, database limits, and success metrics (instead of just staring at the screen waiting for a PRD). they know how to constrain the AI, find hallucinations, roll back a broken git state, and actually know when to stop prompting and write the code themselves. We pretend the job is still about writing raw lines of code, but our own teams don’t even work like that. Someone can spin up v0, Bolt, Lovable, Enter Pro, or whatever and go from a prompt to a working prototype in an afternoon. Even things like Claude Code become a repeatable delivery system once you give it the right skills, test scripts, and deployment checklists. The barrier to entry for building is basically gone. Since the friction to build stuff has crashed, the line between product and engineering is completely dissolving for small teams. We don’t need line-by-line ticket executors. We need product engineers who can clarify requirements, control scope, and take ownership of what the tool generated. If you’re building embedded systems, kernel drivers, or medical tech, yeah, deep memory is non-negotiable. But for the rest of us building standard CRUD SaaS, dashboards, and internal tools? if a junior can build and validate a functional product with AI, explain its tradeoffs, and tell you exactly what they don’t trust in the generated code, but freezes when you ask them to write a basic dict comprehension… should that really be an automatic rejection? I feel like we’re still testing for a job that doesn’t exist… submitted by /u/dependent_berozgar
Originally posted by u/dependent_berozgar on r/ClaudeCode