In my staffing/hiring experience (about 40 people) I find its very easy within about 10 verbal questions on a standard voice call to determine some one CANT cod

In my staffing/hiring experience (about 40 people) I find its very easy within about 10 verbal questions on a standard voice call to determine some one CANT code. How well can they code? That takes more than 10 questions but is equally easy to determine. Keep in mind this is only useful on mid to senior level people with a lot of experience. You'd never interview a fresh bootcamper or CS grad this way. For example - Im hiring for a position where I know the job and the tech requirements because I've done the job myself. Im only phone screening candidates who's resumes paint a picture of someone who works in this area, in these languages, in this tool chain etc. I'm not screening randoms off the streets here - Im actually bothering to qualify people before I bother to screen them. Lets say its full stack web development and I expect the candidate to be a producing team member in 30 days (because if nothing else, nobody off the street knows about our business domain, what the hell a TR-111 device is or a domain specific message format etc - not even to mention where all the bodies are buried in our codebase). Theres a certain baseline set of things a full stack web developer has done more times than they can remember. These questions are intentionally vague. 1) Whats the difference in using the standard GET/POST Request/Response style of web page vs a page that does the same thing via invoking a backend API? Tell me how you build one vs. the other? 2) Someone asks you to build a screen that fetches some data from the database - walk me through the various considerations and how you do this - Give me step 1, step 2, step 3 etc? What if there are search parameters the user can enter? What if this stuff is sensitive and I don't want it showing up in any log files? Obviously theres more than one way to do this so any real answer is a good one. This question covers a lot of ground and almost does the whole job for you. 3) How do I debug Javascript in a running page? 4) What are the most common Bash commands you find yourself using? Any automation scripts you've written? 5) Why cant I rely on developing with some whacky font on my local machine? 6) Talk to me about CSS media queries. What are they for? When do you use them? 7) Language specific stuff like when to use a Hashtable vs. a List? Whats a linked list? 8) Say I give you a hostname and some creds to a remote machine and I tell you theres apparently something going wrong on the prod web app. Where are you going to look, what are you going to look for and how are you going to look? ("I'm going to ssh to the machine like user@hostname ... then dig around /var/log ... ") - bonus if you can tell me where to look next and the likely problem as a result of this search. 9) A junior dev is having trouble getting a server running - some error about a port conflict. How can you help? 10) You get a ticket that requires you implement code requiring a new dependency - tell me how you get all that running locally. Does this have any deployment implications? If the candidate gets this far you can be pretty sure they really have done the work specified on their resume. Now you know they can code. One does not come by knowing answers to questions like this without having written some code. Now - how well can they code? This takes 1 hour during an onsite interview. I recall one interview where this was done very well - the Product Owner handed me a stack of printer paper and some pencils. "I want you to write as close to full syntax as you can without an editor, an end-to-end login page where I get a login failure or a page that shows my address from a database. Think of every page as a file you'd write for your solution. This shouldn't take more than an hour." It didn't take more than an hour either. I had a job offer by the end of the week and I joined a staff of people who had done the same thing. Turns out we could all code just fine. Now, this is an easy kind of interview if you're talking to a person with your desired qualifications. If you're not then its a very short interview. From the candidate perspective, the ones that represent themselves accurately in their resumes knock it out without issue while having spent the bare minimum of time with the process. No take home assignment. No obtuse CS topic that a senior dev hasn't thought about in literally a decade. No contrived problem with a bar, 2 billiard balls and a fulcrum, etc. Just simple, fast and to the point.