Not parent commenter, but the first two are often designed to be rather trivial. No point wasting hours of the candidate/interviewer's time if the candidate jus

Not parent commenter, but the first two are often designed to be rather trivial. No point wasting hours of the candidate/interviewer's time if the candidate just doesn't work out. We've found people who straight up lie on the resume (claim to use a technology then backpedal when asked about it). And there are the kinds of people who just don't show up or can't speak passable English. And there are some who have a history of making CRUD apps for gov and giant corporations, but can't tell when to use an Array or LinkedList even when allowed to google it. The real coding test later is to actually see that the person can code. Normally it's about following instructions, isn't afraid to get their hands dirty, bangs their head on the wall thinking of a solution but actually tries something. There are also lots of people who will build everything except what you ask them to. You tell them to build a To Do List app and they go straight to building logins, adding profile pictures, and then complain that the test was too short. We also often list technical requirements in the job description. The tech stack is always some niche things. It's okay if you don't know it all (nobody really does) but you have to be able to work with the code once you're working on the code. A lot of people list buzzwords for everything they watched a tutorial on. Someone may have 3 years doing something but are actually bad at it. Someone may have learned it last week and want to be given a chance to prove that they're fast learners. Great, if you've been working with that tech for 3 years, this should be muscle memory. If it's new to you, well, let's see your learning process.