There are many candidates who will talk down to people who are not technical. One way to detect that is to either have non technical people during the interview ask questions, or not clearly identify that you are technical if you're in a managerial position. Just a human. Does the candidate respect you. Will they explain things to you?
This is not frivolous. An engineer, especially in a startup, will have to talk with non-technical people (board, advisors, clients, etc). If they have that "attitude", you want to know that before you hire them and make your decision accordingly.
How do they deal with vulnerability, or being wrong, or someone else being wrong? You can be deliberately wrong about something you really know, and then be wrong about something they really know.
Will they go along? Will they correct you and elevate you without having a smug attitude? You want to know that.
Again, this is not some "mind kung fu" frivolous thing. Especially in a start-up, people spend a lot of time testing hypotheses, and often being wrong. You don't want an asshole there. You also don't want someone hiding evidence. If they bullshit you on something you really know because they thought you knew nothing of it, they will do it when you really don't know about the thing that was messed up. You'll have people during an incident doing everything to cover their ass, instead of actually giving all the information needed to fix the issue and stabilize systems.
Even when we hired an accountant, I had a list of questions to elicit these behaviors. In one instance, it became evident that we'll have a problem even asking a question to that accountant.
We had that with some engineering candidates who had attitudes like "Do I also have to explain this to you?", or when you claim you don't really know a lot about a topic, they see this as an opportunity to bullshit.
Besides the ethical considerations of them doing that (or you doing that), it demonstrates low general intelligence to do that in a hiring interview.
Please, no. These have been widely panned for being (1) not reflective of the kinds of skills / decision making need in real, actual, day-to-day work; (2) not even compatible with the everday workflow real, actual programmers use; and (3) in general, are hyper-optimized not to test suitability for actual, real engineering work but for one's ability to... "prepare" (that is, cram for) Leetcode sessions.
BTW as to (2): We're used to coding in the shell and on the file system, right? And with vi or emacs, right? Not in webforms with doc-like editing interfaces - not in a million years, please. Nevermind the (frequently) artificially tricky the problems, and artificially tight (45 minutes or GTFO) the deadlines are.
In fairness, maybe things have changed a bit since I began politely declining to do Leetcode-ish filtering sessions - like maybe they have a better in-page editor by now - but the downsides and limitations to this approach are quite fundamental, and I doubt much has changed to change this overall state of affairs.
My tactic for a mid or jr dev is to poke into some specific things in their resume. They say they know JavaScript, then hit them with a bit of JavaScript trivia. Basic stuff that anyone who has worked in the language would answer in 2 seconds. Also some domain stuff, like if this is a web dev, then have them explain CORS or HTTPS. Then have them talk in detail about a specific project or two. Try to get them to articulate not just what the code does, but why that direction was chosen. Have them explain their role and the other roles and the project team to show they understand teamwork. Ask them how the estimate work. Try to elicit an opinion (PHP or Python, strict or loose typing, AWS or GCP) not to question their thinking, but rather to see that they can make qualitative arguments.
As a dev, I met with the dev team first, then with the business team, then with the operations team, then with the senior execs. Because I wasn’t in the same city, they had me interview remote first, and then on-site. Overall I think I met with 18 people.
Having that many people involved means that you will most certainly find out if the person is culturally suited to work in your startup. This is what matters for a small company. You really want to avoid the guys with bad attitude or culture mismatch.
Oh no! Please! It helps neither the candidate nor the company. Will any of the leetcode exercises map to the job the candidate will be interviewing for?
My preferred way is this:
1. Introducing the candidate to all the team members with whom the candidate is going to work, if selected.
2. Pair programming with few of them on actual task or some similar task.
3. Solo programming on a problem that somewhat maps to one of the tasks the team is working on.
4. Asking the candidate to present the solution to the team on the whiteboard and candidate taking questions from them on the presented solution.
5. Vote from the team members on hire/no-hire decision.
It was casual, conversational, and actually enjoyable.
Look at any github code. Or give them a short homework assignment. (Less than one hour) and then talk over their decisions.
Bonus points if you give them problems they’ll actually work on at the job.
I do a problem with a defined example input, and a general idea of the transformation to be done with it, but allocate the first 15 minutes to the candidate picking the output format, and refining it. You could do a very simple output format with a potentially large worse case space usage, or you could make the output format more complex and get better space usage; anyway, as long as they've got something, after 15 minutes we can move on, and if they're not going anywhere, I can hint them to the simple solution and maybe they can refine it a bit, or at least discuss the problem.
Once that's done, there's two 15-minuteish coding exercises, and the key thing I'm looking for is that they can use the format they just created. Language doesn't matter, but the code should be self-consistent; also I give utility functions for I/O, so nobody has to remember the standard library I/O. Over time, I've learned to do the easier of the two exercises first, so most people can finish at least that one, if it's not in the target time. Also, I've learned that I can't expect any knowledge of bytewise I/O; some candidates just don't know what a byte is, so you have to explain it, sometimes a couple times, but many of those candidates end up doing pretty well, it just wasn't something that was ever previously important.
Having done the same problem over years with lots of candidates, I feel pretty well calibrated to figure out slow but good vs can't code at all vs having a bad day vs won't follow their own format. If someone is having a bad day, and you can tell early enough, the best thing is to try to make things go well as much as possible during your interview; if they're having a bad day, you won't get a conclusive evaluation, but if you can turn the day around a little bit, maybe they'll feel better and relax somewhat and the rest of the interviewers can get a more clear picture.
All this aside, if you really want the best people, you probably want to hire from your network, and then the interview becomes less evaluating the candidate, and more selling the candidate. Maybe ask them about real problems you're having, and see what they think and also if they're excited about solving your problems. It's less repeatable --- you want to ask about current or recent problems, which means candidates don't get the same questions.
You might object to me always asking candidates the same problem then, and it's true it's not an active problem, and it's also an area where 99% of things just use a library because it's complex, but it's a concept that has broad applicability, and I use a very simple form that fits in an interview, and most candidates haven't written anything like it before, which gives it a freshness.
1) anyone who will work with the person should be a part of the interview process.
2) everyone in the interview process must have a copy of the candidates resume
3) everyone in the interview process must have READ the resume
4) foreach, pre-written question, you should have a list of expected answers and what you would score them.
Typical interview consists of 3 question categories, with a forth being money which is a trump issue in most cases (if too expensive then cannot afford them, therefore a no).
Write your questions to support giving a score in each of these categories: Can they do the job, Can they get along, Will they do the job.
Can they do the job is answered by their technical skills as listed in the resume. These skills you need to validate in the interview. I typically ask them to explain what they did / what was their role in a recent project. Expanded with what challenges did you encounter, how did you overcome them. Based on the level of detail, I know if they did it or attended meetings where it was discussed (surprising how often people list meeting attendance as skills).
Communication can fall under the topic of 'can you do the job' as well as 'can you get along'. During the interview, I will ask technical questions where I expect the person to know the answers, and I am just looking for a yes / no. Then I hit them with my zinger, 'Whats the difference between A and B' (with both of the A and B being things they said they knew). In the old days it was typically the difference between a B Tree, and a Binary Tree. No one remembers the difference, not even me, not even after reading it, but I know they are different. The scoring on this is: -10 for a BS answer (I write what they say down, because I need to validate it), 5 for 'I do not know' or the correct answer, 8 for 'I do not know, but I know where to find the answer', 10 for 'I do not know, but I know where to find the answer' and they include the answer in the thank you note (I hate the thank you note, but it does provide value).
Can you get along - that is various people interacting. IMHO 10% of the people in the world do not like you for no good reason. You dislike 10% of the people in the world for no good reason. (hopefully those 10% are the same). That said, you have to gauge how tightly they need to interact with someone as to how valuable their opinion about being able to work with them is. I like the other comment about see how they interact with people who are completely non important. Consistent behavior is a good thing.
Will you do the job - This gets down to why they want the job, besides the cash. Everyone wants money, what you need to determine, if you hire this person for x dollars a year, will they leave to a competitor for x + y dollars. (where y is 10% of x or less).
You must take notes during the process. After the interview score them. Have everyone score them. A common tactic is to try to be the first or the last to interview because people favor them. If you score immediately then you quantify your choice, and not a whimsical decision.
