My one big tip: One vice that I see among hiring managers is an unwillingness to ask tough follow-up questions. If you ask a question and there is any vagueness

My one big tip: One vice that I see among hiring managers is an unwillingness to ask tough follow-up questions. If you ask a question and there is any vagueness in the answer, you need to drill down deep until all vagueness is eliminated, so you understand exactly what the person knows. Follow up on what's said, but also follow up on what is not said. Here’s a real-life example. I asked a recent applicant (for a fullstack software job, where we were hoping to hire a novice-to-mid-level engineer): Me: How would you improve a situation where a page is loading slowly and you suspect the problem is related to the database? Applicant: Well, I’d start by checking the HTML, is it correctly done, and then the CSS, is there any redundancy? And then the Javascript, is it correctly written, is it minified? Can we speed that up at all? Check the timeline, the API calls, see what is slow. Me: Okay, great, that’s a good start, but what else? If the problem is not on the frontend, then what? Applicant: Uh, well, then, I guess I need to look at the backend database model code. Is my database model code concise? Am I fetching the data needed, without any excess? Me: Okay, great, that’s a good start, but what else? Applicant: Uh, what else? Well, uh, we really need to look at that database code. Is the model bloated? Can we slim it down? Me: Yes, okay, you basically said that already, anything else? Applicant: Uh, well … uh, you need to check the HTML and the CSS and the Javascript and then, uh … API calls … uh ... the model code, make sure that is cleaned up. That needs to be lean. Me: Yes, okay, but you said all of that already, anything else? Applicant: Uh … well … the model code … and uh … Me: Have you ever worked directly with a database? Applicant: Uh … not much? Me: If you get unexpected results from your model code, do you know how to debug the query? Applicant: Uh … I guess I could … not really. Me: Have you ever looked at the “slow query” log? Applicant: Uh … no? Me: Do you know how to run EXPLAIN or ANALYSIS? Applicant: Well … uh …. no. Me: Have you ever written SQL by hand? Applicant: Uh … no. Me: Are you aware of any differences in dialect between the SQL of MySQL and the SQL of PostGres? Applicant: Uh … no. Basically, they were somewhere between a novice level and a mid-level engineer, so they knew the frontend reasonably well, but they didn’t know a thing about databases. Which was okay, because that was what we were looking for. We still hired them and they turned out to be great in some areas, and they were eager to learn about the things they didn't already know. But obviously, if I'd been hiring a senior-level engineer, and it turned out they knew nothing about databases, that would have been a problem. The crucial thing is that I kept asking the question, over and over again, until I had the full answer. In this case it was easy, but sometimes it can feel aggressive, asking the same question over and over, which can leave either you or them feeling uncomfortable. But you will never be any good at interviewing people until you learn how to tolerate uncomfortable moments. The goal is to find out if you want to hire someone, without wasting their time or yours. And asking questions like this, directly, and digging deep, is a much faster method than handing out homework assignments and then waiting a few days for them to complete it, then reviewing it yourself, then discussing it with them. And such direct, factual questions, as above, are at least as objective and as any “objective” test that you might invent.