Want to know the secret to interview developers? Here are the only 3 questions you have to ask:
1. What do you do for fun when not at work? … dig into to questions from here.
2. What is the coolest thing you ever built? How did it work? How long did it take to build? What language? What architecture / framework? What was hard about it? … you get the idea.
3. What are your biggest pet peeves when it comes to reading other peoples code?
Question #1 breaks the ice and gives permission to the candidate to be themselves. Look for common ground. Connect with them. Learn who they are as a person.
Question #2 gets you to see their passion. Talk to them on their ground. Give them the benefit of the doubt. Ask them hard questions, but don’t intimidate. Just go deep. The candidate cannot fake this. It’s not possible. People without the experience they claim are painfully obvious here.
Question #3 gives you two things. 1. Is this person openly critical of things looking to improve them? And Is this person a jerk? I call this the Jerk Trap. Jerks jump right in to being Jerks. After all you just kind of game them permission here! — I would ask though you be careful about excluding neurodiverse people who may not be able to control tone or navigate social situations well. These people will tend to be direct. Don’t confuse directness with being a Jerk. They are not the same thing.
I’ve interviewed a lot of engineers in my career, and tried a lot of things. This methodology has yet to fail me.
EDIT: It’s sad I even have to point this out, but in #1 you are looking to connect with the person on a human level. It’s not bait them into talking about coding outside of work. If you do that or think that way you are being discriminatory towards people who can’t code outside of work… you know like single mothers. And people wonder why we don’t have more women in tech. Stop equating passion with > 40 hours a week. It’s bullshit. Stop.
> 1. What do you do for fun when not at work? … dig into to questions from here.
Sorry but I think it's a bad question. What if the answer is "Oh I don't have much spare time these days, I make dinner for our toddler son and put him to bed. My lesbian partner can't help much because she's expecting in a month." It's a trap leading to unwanted information - many of which would be downright illegal if factored into hiring decisions.
There's a reason why all the big companies emphasize never to ask anything about nationality, ethnicity, marital status, religion, blah blah. You don't need to know, you don't want to know.
Oh, congratulations!!! Do you know the sex of the baby yet? What an exciting time, I bet you have lots of preparation going on. I also have a child and (blah blah bit of history)
So we ask this question to get a bit of an idea about the candidates hobbies which tells us about them as a person, - are you outdoorsy or indoorsy? Are you a movie buff or a reader, or a rock climber or a painter or a poet? Or something even more interesting?! before you were so busy, how would you spend your non-work time?
That way:
Puts them at ease, shows you have empathy for their situation, find common ground, explain the reasoning for the question, gently nudge the conversation towards what we were looking for.
It’s not rocket science people it’s just conversation skills.
That’s going into the territory of protected classes and can backfire (depending on where you work). My approach is that if a candidate brings up any info related to a protected category is to not engage in it and move the interview along.
For anyone else reading this, do not ever get into a conversation about family during an interview. That is just straight up making yourself a target for engaging in discriminatory hiring practices.
I love this style of interviewing, but I have been discouraged by HR/management from asking questions like these because they were deemed too subjective. Personally I believe this was directly related to their D&I pipeline efforts and the "subconscious bias" we were told we all had.
I use the person's CV as a driver for discussion. Just let them freely expand on their professional experiences, what they liked, what was hard, how they'd do things differently, what they learned, etc. And not just the technical stuff, but the social aspect of work, team dynamics, workflow.
Let the candidate lead the conversation. People love being listened to. Where they take it is way more revealing about them than any fixed interview grid. And they leave the interview with a smile because all they had to do is be themselves.
I don't see how one could be sued for discrimination based on information that people reveal of their own will.
How is somebody's personal life any of your business when interviewing someone for technical skills? Asking people about their hobby projects, expecting them to be coding too, is propagating the unhealthy practice of needing to work 10-12-14 hours a day just to stay relevant in the industry.
From a human side, I would hire someone who decides to take care of their kid after hours instead of honing their technical skills. They tend to be a lot more responsible with their work too.
100%, the future of tech hiring needs to be more data based and less “this is my kind of person” based. This is why prestigious companies have hiring committees and have well honed processes.
I strongly disagree based on my experience. I've worked at a place that had a very honed process for (supposedly) removing bias in interviews. At the end of the day we just pretended to removed bias, I'm not even sure that's possible with human beings. People hear what they hear, and you can't control for the layer of projection and filtering one will do during an interview.
At it's best we tended to reject too many great candidates because our rubrics were so rigid, and it didn't let us make room for folks that were clearly amazing but didn't answer the questions in just the right way. Seriously, the talent we passed over was truly world class.
There's a lot to be said for all of the non-verbal and subtle information that's conveyed in an interview. I think that throwing that all away is foolish because you're not really doing much better at removing the bias anyway.
> This is why prestigious companies have hiring committees and have well honed processes.
Wouldn't it make more sense to consider the fastest growing companies, or perhaps the subset of fast growing companies with the most profit per employee?
I can see that being an issue, I guess it depends on how the question is asked. My current job, I was asked a variation of this question, it was, "What do you do outside of work other than coding?" Followed up with a, "we are curious as to how you turn off work." However, my employer is also big on not wanting us to burn out at slinging code.
Maybe it would be more appropriate to word it like that? Maybe not?
For the same level of commercial experience, someone who spends most of their time outside work coding has more experience coding than someone who doesn't, and they probably love it. I think these things are worth knowing about a candidate when hiring?
That is awfully close to just discriminating against candidates who have families or especially single parents. This level of gatekeeping that a programmer who decides to have a full life outside of work is inherently an inferior programmer is a really superficial way to look at it. Equation passion with "Is this person willing and able to spend 60 hours a week coding" is a disgusting attitude that should just completely end in this industry.
In my entire career the single most talented Programmer I ever knew was a single mother who logged off the computer every day after 8 hours period, and choose to spent her life with her kids.
What you are saying is the same thing as "a programmer with 5 years of experience can be much better than one with 10", which is true, but does that mean that we shouldn't consider how much experience someone has? Nobody said that more is always better, just that it isn't worthless information.
People who want to have families often split the difference. One partner gets a government job that doesn't pay very much, but has great benefits, job security, and work/life balance, and the other takes a more demanding job with longer hours that pays better.
Or it just points out candidates who are too unskilled to pickup coding practices on the job, or who have families, or who are likely to burn out in 6 mos of working in their new job because they worked 40hr weeks then went home and worked 40 hours more.
Yes, or. That 'or' includes the sort of person that is so endlessly fascinated with programming that they can't stop themselves from creating things with code in their spare time.
Alternatively, they could be terrible coders and looking to improve outside of work, whereas the question gleans no substantial information for those that don't code outside of work.
I’ve asked question 1 many times when interviewing candidates, and it’s fine if someone comes back and says they don’t code much outside of work. I’m not expecting the answer to be “I spend my free time coding”, and it’s certainly never a subtle dig.
But if that is their answer, it’s also a gateway to a more natural and relaxed conversation about the tech they care about and what makes them tick.
I’ll often learn far more about a person that way than the typical “tell me about a project/time when…” style questions.
This sounds like a recipe for an incredibly inconsistent interview process.
I know engineers love open, discussion-y interviews and senior interviewers like giving them, but the evidence just doesn't bare it out. "Work sample tests" and "Structured Interviews" are the most predictive of on-the-job success from the published research I've seen. No matter how much I'd prefer to have a freewheeling conversation as you describe, I have to bow to the evidence.
You're virtually guaranteed to not be terrible given this self-evaluation. You might not be some senior-level elite developer, but I'm not sure I've ever met someone who said this who was truly awful.
What is the interviewer supposed to hone in on for that?
Like if i was to answer that honestly, it was fixing an obscure i18n bug for an underserved language group. I felt it was cool because it was such a small amount of work but made some people inordinately happy. In many ways i am much more proud of this 20 min bug fix than all the big technical projects i've done. But if you asked me any technical questions about it, the answer would almost entirely be - i used the architecture that already existed, because i was fixing a bug not rewriting the code base.
I have a couple of basic android apps and a site in Angular. One of my android apps had a few interesting problem. They would probably easy for experienced people, but they were hard for me when I was just learning. One the issues wouldn't even be applicable since we can use fragments today.
If you’re interviewing for a junior position that would be fine. If you’re interviewing for something higher level that answer would definitely raise some red flags.
The point is to see if the experience you claim matches what you have actually done.
That's the condensed version of the answer for here. Obviously id go into the technical details in an interview.
I work for a finance company. The vast majority of the devs, including seniors, haven't released any software outside of work. Maybe 10% have. It seems this is true for other non-tech industries too.
Even on here, do you think more than 50% have released something they made by themself, that is more advanced than a simple Android app? Obviously there's a lot of talent here. I would be surprised if the number is higher than that.
"What do you do for fun when not at work? … dig into to questions from here."
Made me think the other questions are follow-ups to these.
Eh, when you work on large systems in a large and highly regulated company, it's not very exciting. There have been some interesting components to those systems, but in general they have been mundane business topics with tight guiderails and little freedom. I mean, the majority of people in the world don't get "excited" about work - it's just the means of survival.
I ask a question kinda similar to 1 sometimes when I interview people. Even when their answer isn't software related (for me it's more fun when that's the case but I try not to be biased), there's a lot of room to dig in deeper.
Like if someone says their goal in life is to make the best tasting sourdough, ask them how they go about doing that. Researching new recipes? Starting with a base recipe they like and making small tweaks? Optimizing for their own taste preferences vs the tastes of the people they share it with? Etc.
Even if their hobby isn't collecting Github stars, you can still learn a bit about their mindset. Plus I've found that getting someone to talk about something they're passionate about for 5 minutes is a good icebreaker to start an interview.
#3 is one I've had to think on a lot recently and I think it comes down to two things:
1) When the person who wrote the code is no longer available to talk to. Having even a 5-10 minute chat can massively speed up my comprehension of someone else's code and save a lot of time.
2) Unused code that hasn't been deleted. I think everyone should strive to clean up their codebases. I'm not exactly blame-free here either so it's something I try to apply more and more as the codebases I work on start staying around for longer.
This. All the best places I have worked at in my career have basically followed this formula. And in fact these questions are fairly similar to the original YC application, with the exception that the question about your favorite tech stack was separate from the question about the coolest thing you've built.
In contrast, the places that have done tech interviews have generally been awful to work at. Less intelligent people, less interesting work, worse management, etc.
Many below gave various reasons about it being less than ideal to ask "personal" questions about hobbies etc, but I think I have had such question asked of me during every interview. It never was at the beginning, usually after we've done talking about technical stuff and before the money conversation.
Personally I never had a problem with it and from the interviewer point of view it helps lighten the atmosphere a bit talking about out of work stuff.
> It’s not bait them into talking about coding outside of work.
I've been to work for companies that say anything you build while employed at company belongs to them unless you go through the proper channels and layers of red tape to discuss the projects with them to ensure that anything you are working on does not involve any company IP. This could sound like baiting for a different direction than the other comments are alluding.
I hated interviewing SWEs at Google, and the way I got out with it while still doing my duty was to interview the patent lawyers! They always had one engineer interviewer and I was it. My stock answer for why I did it was, "Hey, who wouldn't enjoy torturing lawyers?"
Actually, I loved it. You might not be able to imagine this, but I actually like lawyers, as a rule.
Since Google insists on giving candidates a problem, I took a patent from a previous job that I was familiar with, and said, "OK, we're going to pretend I'm the inventor, and I'm going to describe this invention to you. Your job will be to write the first claim."
This is pretty similar to their actual job, at least on the patent prosecution side. They have to come up to speed on an unfamiliar technology quickly? Well, that's what patent lawyers do. Most of them did pretty well on the test, too. It was way fun.
Unlike in a SWE interview, I never heard anything after I gave my feedback (with a SWE, you would see what the other interviewers said). The only way I even heard if they were hired was to check a few months later. I didn't know if Legal even paid attention to me.
Years later, I joined Legal and found out they'd been hanging on my every word.
Oddly enough, this sounds like a lot of fun. For the most part, I got to know lawyers as incredibly hard-working people and if you show them a little bit of respect and understanding towards their profession they are an absolute joy to work with.
The best thing was, I had a specific job: "find out if an engineer can get along with this person?" Whether they were good lawyers or not was someone else's question to answer.
Didn't like this article at all. The writer's style is dismissive and combative in a way that's at odds with the message it's trying to convey. It's not an idiotic myth that most people aren't good programmers and it's not arrogance that makes people think that it's very important to make sure the wrong person isn't hired. I don't think this because I've spent too much time on Hacker News, I think it because I've worked with a lot of people over the years and I know how a team can be dragged down by a bad hire.
Of course you shouldn't humiliate the candidate, that's never the right thing to do. But there's a huge gap between maintaining a high hiring standard and believing that "everyone else looking for a job is an idiot, and our job is to expose them, to teach them a lesson, to humiliate them till they quit." The bulk of the advice in this article is fine, but the hyperbole is just plain annoying.
Also, seeing people site the no asshole rule is a warning sign for me. I worked at a place that constantly mentioned that, and let's just say it was clearly ineffective. Assholes rarely think that they are the asshole and are perfectly comfortable citing that principle.
I feel like in the third situation it means that the team is way too picky and that’s why you should try to avoid job postings that have been open for a few months or more.
Once you do enough interviews, you realize this isn't a myth. Okay, maybe most is too strong of a qualifier. But the reality is that a title of Senior Software Engineer doesn't imply the ability to translate human problems into machine-executable code in a structured way. It's very possible that a "Senior Software Engineer" has been working at a small consultancy on the same project for 5+ years, has few if any technical teammates, and spends most of their time copy and pasting StackOverflow answers and doing "guess and check" programming to do bug fixes for a legacy VB6 or FoxPro app. I'd know, as I've worked with those people.
That being said...
> The interviewer asked me a very basic question– something small like how to create a table(or something silly like that).
If you're asking syntax questions in an interview, you've already lost. For technical interviews, the thought process is far more important than the end result. Again, programming is the act of turning human problems into machine code in a structured, repeatable way. Pseudocode is sufficient for this. Forget whether you should be using `sort` or `sorted` in python? Me too, so just tell me what you expect the sort method to do and move on.
So yes, asking for the SQL create table syntax in an interview is absurd and the author is right to complain here.
> Actually talk about their fucking resume... You can easily filter out people who just coasted along vs those who accomplished something.
Sorry, but you cannot. Some people are excellent at bullshitting and making themselves sound like incredible workers, especially if they've had time to prepare. You'll hear amazing stories of late nights and heroic effort, but they were often done by other people and merely observed by the interviewee, or just fabrications.
This. I’ve interviewed some amazing talkers with epic resumes. I’ve had people try to hog the mic to charm me but then when it came down to coding they couldn’t produce any working code in the language of their choice.
All the most advanced computer science research areas right now basically come down to guess and check. E.g. AI, ML, NLP, etc. The folks behind spaCy have a good talk somewhere explaining that this is the reason why there isn't more academic funding things like NER, despite the fact that it's an insanely valuable problem.
But regardless, the best programmers you know probably spend most of their week doing guess and check.
That's not the kind of guess and check I'm talking about. I'm talking about just copy and pasting things, moving variables around, etc. without any real methodology. Just doing arbitrary changes to the code until it appears that a problem is fixed, because they don't have the deeper understanding to explain why a problem is occurring.
despite the fact that the specific problem has been memed to death, i can still reliably wash out 70% or so of the interview cohort i’ve interviewed by fizzbuzzing.
I think this depends heavily on your candidate source. A few bits of anecdata:
1. A couple years out of college, I went back to my alma matter to recruit interns. I stood at a booth at a job fair and chatted with people. Anyone who seemed interesting I invited for a 30-minute interview the next day (9 people). The next day I had all 9 people do fizzbuzz on paper (I know, I know, I was young!) - every single one passed easily and it filtered out no one.
2. More recently, I was recruiting off of workatastartup.com for senior devs. I went through a few dozen first-round interviews and didn't once come across someone who couldn't code.
3. More recently still, I was working with some recruiters who would send resumes my way. I was looking for a specific combo of two common techs and I started out giving a first-round interview to anyone who listed any experience with both. I found that something like 60-80% of these candidates would *not* have, (in my opinion), been able to code fizzbuzz.
It was interesting because, until #3, I'd never really believed the "most people cannot program" thing - at least not after my experience with #1. The lesson I took was that it totally depends on your pipeline. If you put a job listing on Indeed.com or whatever, you'll get a lot of people who cannot program. If you use other channels or do any other form of screening (implicit or not), you may get almost none.
It’s incredibly uncomfortable when a candidate can’t fizzbuzz. I used to use it as a warm up before hiring in big tech, where the process is very defined.
I had one candidate take the entire first half of the interview to solve it, and I guided him very strongly the entire time. By the time he was half way through, he had so much sweat pouring from his face he looked like he was running a marathon. It was very awkward and uncomfortable for me.
Like fishtoaster’s #3 above, these candidates came through recruiters where we specified the technologies we wanted.
I mean something has to be going on here right? I've run 6 week programs for elementary school kids where at the end the pass rate for "and code something that prints the numbers 1-100" would be higher than that. Like there is no way only 30% of interviewees have taken a single programming class and that's miles ahead of printing 1-100 or fizzbuzz. Is it something with the interview process? Is it some freeze up because the question seems so easy people are doubting they understand what they need to do correctly? Is there some endless supply of software engineer candidates that don't know how to use a computer, cheated their way through school, but are sure they can land a position anyways if they just interview 50 times?
I don't want to amplify stereotypes, but I can't help but notice there's a correlation between the candidate being in India or Pakistan (for a remote job) and not being able to program.
The number of people who find fizzbuzz hard makes me wonder if there's something that I find straightforward to understand in it that's actually harder than it appears, which makes me avoid it as an interview question. I want to find good devs, not good Fizzbuzz authors.
Yes. Fizzbuzz is redundant, perhaps by design. If you start thinking to optimize the redundancy away, like “why do I need to divide by 15, if I am already dividing by 3 and 5”, you spend some precious 30 seconds thinking, and look exactly like an idiot who doesn’t know how to program at all.
The secret there is to vocalise your thought process. Interview puzzles are as much about assessing the candidate's critical thinking skills as they are a filter for programming knowledge.
Yeah, I've seen it, too. It's terrifying. Some of the candidates I've rejected over the years have verifiable years of experience yet can't actually produce very, very basic working code.
What's more likely: that they managed to fool their boss and colleagues for years only to be found out by you, a complete stranger, in a 45 minute interview? Or that they were nervous, made a small mistake, and then panicked/ froze up?
I've worked with these people "on the inside." My belief is that, yes, some of them do fake their way in and manage to hang on for a shockingly long time.
I also agree that some of them panic from the induced stress of interviewing. I try to keep my interviews very cordial, I've been there before, too, so I'm sympathetic, and I also suffer from horrible imposter syndrome, because I am a CS college dropout, despite the fact that I've had a wonderful career with dozens of major victories over the last 16+ years. I really do get it. Despite that people who cannot program find their way in front of me, interviewing for Senior+ roles.
A recent example is a Senior Software Engineer new hire (I did not interview this person) who was tasked with moving a git repository to a new upstream as part of a larger migration in the engineering org. This person proceeded to try write a sprawling bash script to handle the process in order to "preserve history."
Clearly this individual doesn't understand git at all. The script wasn't even doing anything. Their other tasks, which were application development tasks, demonstrated code that was also somewhere around an intern/associate level.
I left that role very shortly after because when I brought this to my management team it was made clear to me that what we needed was warm bodies. That person is still employed by my former employer, over 9 months later, making a 6-figure salary with an annual performance bonus and stock grants.
> Clearly this individual doesn't understand git at all. The script wasn't even doing anything. Their other tasks, which were application development tasks, demonstrated code that was also somewhere around an intern/associate level.
I think I must always take "can't program" a bit too literally, because it sounds like this person very clearly can program but doesn't understand git. I have worked with enough senior/staff engineers from exotic computing environments (mainframes, academic/scientific computing) that the idea of a senior engineer who doesn't know git is not surprising, but I would have expected such a person to ask for guidance/help. I found myself in similar situations when I joined MSFT despite having only used Linux/OS X for over a decade.
I guess maybe I would suggest that you phrase your assessment of someone like that as, "this person is unfamiliar with a standard tool and does not produce work that meets my code quality bar" instead of "this person can't program," as the implies that they got and have kept their current job through deceit and/or outright fraud, and were caught attempting to defraud you.
I’ve still never seen an interviewee that couldn’t pass fizzbuzz and I’ve interviewed a lot of folks, albeit mostly in the Bay Area. Not that I ever have asked fizzbuzz, but because the problems they attempt to solve are harder and already include similar concepts. Most do ok enough with those to easily pass fizzbuzz. Maybe I’ve been lucky.
yeah I really don't understand this "catch them out" mentality.
My approach is to try and make the candidate feel relaxed, as I want them to show their best self in an already stressful situation. Following this it's about giving them the opportunity to demonstrate their skills.
If you go into an interview with a combative mindset of "filtering out the lemons" and then complain how hard it is to hire good people, you really ought to take a long hard look in the mirror.
I have the following framework when interviewing (either side of the table)
1. Both parties hope it's a match but of course worry about making the wrong choice. Think: the interview wants me to do well, I need to help them say yes to me.
2. Programming ability is a necessary but not sufficient skill for a real programming job. How you are on call, how you are with brainstorming, how you are hashing through requirements, how you are when you make a mistake, how you are when you are being coached - all matter and the programming interview is generally structured to get signal on those things.
I think most people who make themselves crazy / hate interviews / are befuddled - it's because they don't see this.
Interesting take. Somehow I feel confident and positive about all the things you call out, but struggle with the idea and situation of doing artificial coding puzzles while someone is watching, but judging instead of helping like a pair would. I enjoy doing coding puzzles for fun, but not while being watched and judged and a clock is ticking.
// doing artificial coding puzzles while someone is watching, but judging instead of helping
Look it's definitely an interview and you're being evaluated but good interviewers help you a lot - eg hint when you're over or under thinking something, ask about edge cases you neglected, etc. If you think of the interview as adversarial you probably miss all of that. .
// coding puzzles for fun, but not while being watched and judged and a clock is ticking.
Have you ever troubleshooted a production issue with millions of dollars at stake every few minutes of down time? Lots of eyes on you and time pressure.
Like I said, the interview gives signal.
Remember, nobody is at their best in there situations. The interviewers aren't expecting perfection, they are expecting reasonable performance given the situation. They are usually calibrated on dozens or hundreds of other interviews.
There are very few systems that will actually lose a company millions of dollars every few minutes of downtime.
I have done high stakes production troubleshooting many times. It’s not remotely the same as an interview—not even in the same ballpark. Everyone of those eyes wants you to succeed and will help you in any way they can. And if they aren’t being helpful, I politely tell them I’ll solve it faster if I can focus without people looking over my shoulder.
The fake adversarial system created by coding interviews is why I prefer pair programming with a candidate on a novel problem.
This seems to be a human trait; where authority mixed with lack of responsibility leads to terrible outcomes. Not only in programming interviews, but across the spectrum. My first awareness of this is in teacher-student relationships, where faculty deem themselves in high regard because they are continually interacting with people who are ignorant of the facts they have been teaching for the entirety of their careers.
Been in the technical interviewer role once. I did feel like an asshole for asking what seemed like a trivia question but they were all very basic things meant to be a starting point to pull on the thread and use that to have a conversation. I asked multiple questions like that because they keep saying they didn't know what I was talking about. This was a non-entry level security job and the questions were simple things like "do you know what a sql injection is?" Or "do you know what a dns record is? Is so, what is the purpose of the SOA record?" It was fine if they didn't know really, "I know what sql is but I don't know what a sql injection is" is a good enough answer.
It was horrible. Never want to be the reason someone didn't get a job again lol.
I agree with the article - some common styles of interview are designed to produce arseholes. Which, fine, if you want to employ only arseholes and people who like working with arseholes that's what you should be doing. Likewise if your workflow is 90% programming trivia questions and 10% meetings. It's useful for me as a candidate, the sooner you show that the sooner I can get out of there.
The bit at the end about trying to discover what candidates are good at and see them actually working... I'm shocked that so few interviews actually do that. I get that it's hard in tiny companies where you have one vaguely technical person who realises they're out of their depth and is hiring to fill that gap. Everyone else has no excuse for lousy evaluation of technical skills.
Other than the assholes, there is also the "I just found out about this 10 mins ago" guy. This guy doesn't have any questions and hasn't prepared.
This means when they ask him for feedback he'll say "Oh he was okay. Not very technical"
To solve for this guy, you need to have some very good questions about technical problems the company may be facing and then you need to be able to have insights on how they might solve this.
You essentially have to structure the interview for them. Give them the questions and then you answer and then you have to impress.
The aim should always be to impress and be liked unless you have someone who is out to prove you wrong. With those types you need to show technical superiority in addition. These types are usually small in number though.
I love the open-ended hypothetical questions that have to reframe into behavioral questions so that I can show what similar things I've actually accomplished in the past.
This is really big; we've been using the same basic "is this person a big phony" set of questions for a long time, and it immediately filters out people who just have no knowledge. Stuff like what is a Boolean variable, what is ssh, what is asymmetric encryption, name 3 hardware components of a server, what is a primary key, etc. I've seen people with resumes full of tech jobs that fail at all of these. And I don't mean slightly off, I mean no clue at all. We don't require a perfect score or anything, and recognize language barriers, but it becomes super clear super quickly when someone is just bullshitting.
We used to call it the elevator test: can a candidate navigate the elevator and make it to the interview. Partly because we got ghosted a few times, but mostly for the number of interviews where we'd sit candidates in front of a PC, show them some code in the language we were advertising for, and say "add a trivial function". Make a button show some text level. The failure rate was a bit terrifying for "2-5 years experience with X" programmers.
I stopped bothering with questions before that point, I'd read their application, look at their resume, then get them in to play with a computer. The good news is that it actually found the people we needed, the bad news is we never found an effective way to pre-filter the ones who couldn't (and even a couple who said "I've never seen this before" when looking at the code!!)
In my opinion the reason why programming interviews are the way they are is that they are primarily testing for a kind of person rather than programming ability. They are testing for the kind of person that is willing to jump through hoops.
I see this meme a lot and don't think it is a useful framing of what is going on. I'm sure there is one company out there, but I'm willing to bet that none of the companies that matter have actively sat down and a group of people decided to have programming questions explicitly to find people "willing to jump through hoops". Clearly, there are much better ways to test for that specific trait. Including actually asking them to jump through a hoop. I'm not debating that it is a welcomed side-effect that only fails in rare cases like the brew developer at Google.
Mostly, I think this is just the result of companies looking to satisfy mainly three competing tasks. One, how do we assess someone can code. Two, making a standardized interviewing approach that many different people can perform. Three, doing it all in a time/resource efficient manner. Obviously code reviews satisfies the first but present very serious reproducibility and time requirement issues. I posit that programming leetcode style questions is the solution that most companies think balances the three. It feels bad as the interviewee because it is a fairly specific skill of programming that you need to practice and you cannot opt for another method to better illustrate your ability.
> They are testing for the kind of person that is willing to jump through hoops.
That's true, but it is meant as a different filter when applied to a large number of candidates.
I went through a bunch of leetcode style interviews last year with some very odd interviewers - the oddest was a Sr Principal engineer asking me to manipulate linked lists with recursion.
And the comment he made after I wrote the code was that "We don't care if you write code at work, but we want to know you like writing code enough to not see it as beneath you to do. To make sure you're not some whiteboard architect, because everyone you are supposed to lead will be writing code."
I had been looking at the interview as a sort of idiot catcher before that point, but suddenly it seemed like a good filter for respecting the effort at the lowest level of the profession.
What makes you say that? I've been involved in a lot of hiring processes, and I would say that is nearly the opposite of their intent. Don't attribute to malice that which is adequately explained by incompetence.
I don't think it's malice. I think it's just an emergent property of the process. Large tech companies want people who will be a cog in their machine, it's as simple as that.
To offer a counterpoint, you can also say it’s testing for people who are willing to do the work to get the task at hand done, and filter out people who say “well I could do that I just choose not to”.
Triangulating skill level of prospects can be challenging the further down the Niche Hole you go. At the very edge of the problem space the prospect is going to fall off a cliff; it can't be avoided, there's just too much specialization.
However . .
When prospective associates are responding to these sorts of questions, it's possibly more informative to see how they handle questions that they don't know the answer to.
Native intelligence and initiative outweigh a set quantity of specialized knowledge; far more important to find out how a prospect thinks about the problem and how they respond to these situations under pressure.
Problem here is that the interviewers need to know their stuff, and, regretfully, that's not been the case for virtually any interview board I've assisted. All the participants were far, far too high above the levels where work happened, well into the vertiginous expanse of Aero/Def Management Brain Rot. Best I could do was wave my hands vigorously while silently mouthing the words HE DOESN'T KNOW WHAT WHITESPACE MEANS . . to no avail.
Thing is, I know it's not just my industry. It happens in the "normal" world too. Some guy makes a thingy with Framework X, leaves, and then it's practically impossible for management to find another random guy who knows Framework X in just the same way, because damned if management knows what the heck Framework X is.
Something I have rarely seen mentioned: ask the interviewee about the things they claim in their CV. Sure, it takes some prep time, but it makes them feel more comfortable, and it also weeds out the bullshitters because even without the deep technical knowledge in that area you can just ask them to talk specifics. If they know their stuff, they will dive into something super detailed. If others did the work and they were just along for the ride, they will gloss over all the details.
Yeah, I think there's a surprising amount that can be learned just by having a technical conversation, and it's the interview format that is least likely to cause performance anxiety. That said, I've been snowballed a couple of times by people who could somehow talk exactly like a productive person, yet not produce anything. The huge variety of people is what makes interviewing so hard.
I was so confused the first time this happened. I kept asking about these things they said they'd worked on and could not get any details. Now I understand how many people are able to coast and never contribute meaningfully. These people need to be coached out of the profession.
A not insignificant portion of people I meet in IT are freeriders. They just jump on any project that has a high visibility and do minimal, shoddy work on it just to be involved. Quite often these people then also hold fairly high titles in the corporate structure. Some people even manage to transscend companies with this by working on public-facing projects.
However, a lot of them will have real problems when switching companies and being faced with a real technical interview as they are severely lacking in technical depth. Ask them about anything deeper than a manager's understanding of the topic and they will waffle on without answering the question. "What security measures did you take in your code?" - is a good question, followed up by a more specific "how did you prevent injection attacks when you did X?" (YMMV). Usually these candidates have no clue what that even is, compared to someone who actually had to deal with the nasty bits of the job the project hoppers can't be asked to deal with.
This. I ask people to explain in 5 min a technical achievement/contribution they are really proud of, and it’s been crazy to see people who mention all the buzzwords in their cv to not be able to explain anything or dive into the slightest details.
People bs-ing in their cvs about their actual experience is one of the factors interview process has become like this.
I imagined how should I act when I forgetting the SQL table create command in an interview.
1. I admit I am nervous so much that I just couldn't tell my own name.
2. It's just strange for first look that I don't remember, but we create tables so rarely, that it's not a surprise.
3. Okay, let's try to figure out the command, my first hint is that it should be "new", "create" or something. Let's recall, how to deal other way, say, delete or modify tables: "drop table", "alter table" - so my best hint is "create table" or "new table". (Offensive notice: if you learnt SQL one day before the interview, this gonna not work.)
Great, go on, it's pretty sure it should contain the list of fields, define them: names, types, and some constraints, whether it can be empty etc. Maybe this command defines the indexes as well, then every index should declare one or more fields, ascending/descending marks per field. Oh, a table unique key is also can be specified, at the field specification. Finally I notice, that different SQL servers may have different syntax and even features, like choosing storage system for the table (MySQL: InnoDB etc.).
That's the _content_ of the SQL's create table command, withot any syntax. I think, it's clear, that I would have no problem with writing a table creating SQL statement.
If you can not solve the "I-forget-the-syntax" problem, probably (another offensive statement, sorry) you're not for this job. In real life, you will have even more stressful situations, and you have to solve them, or at least DO SOMETHING. What you've done was NOTHING.
The solution for this, along with most interviewing problems, is to get your team together and come up with a very clear picture of what it is that you're looking for in a candidate. Hash it out and write it down. Now take that list and write out a group of questions that help to suss out whether or not the candidate has those things. Use the same group of questions for everyone that you interview for that position. Nothing good comes from asking gotcha questions. It's more likely to happen if you don't have a clear, documented process.
Depending on what your needs are, you may need to do a technical interview. Do the same thing with the technical interview, figure out your needs then write your questions. Have a similar group of people doing the situational interviews do the technical interview, preferably the people the candidate is going to work with. Find a way to make it collaborative if you can. Seeing how a candidate works with other people is nearly as valuable as seeing how technically proficient a candidate is.
Interviewing is a multifaceted process that depends on many variables. Unfortunately google and other similar companies influenced/contaminated so much the general idea of what an interview should look like that many, many people believe that a person writing in 15 minutes a sloppy solution for what's essentially an academic exercise is the gold standard for measuring someone's skills.
I have no problem solving exercises in interviews as long as we're talking about one session of at most one hour. I was contacted by recruiters of companies that expected me to go through many rounds of interviews that would span many weeks. lol
I always reply that I'm already employed, that for me their company is just like any other company and that working for them is not a privilege, it's just a job.
Anyone else surprised how many candidates can’t code without autocomplete? I let candidates google answers and some still gripe about not having autocomplete. We code in a web app, so it makes me wonder how they would perform on a whiteboard with no google or compiler feedback.
I can write code without autocomplete, but given that most of what I write is Swift for iOS/macOS where verbose naming is the rule (and thus, is probably what I'm interviewing to do) it can be painful because often I don't have method signatures, etc memorized because heavy autocomplete usage is a must to not drag down speed. When faced with writing in a plain editor or whiteboard I'll usually ask if I can write non-compiling pseudocode because I'm likely to have name errors all over the place.
Why is it surprising that people are less productive without their tools of choice? Why does it matter how they perform on a whiteboard without Google or compiler feedback? Is this how you work on a daily basis?
We set up all these artificial handicaps and are then surprised people do badly in interviews. Just let them code using their own machine and IDE, and any other tool they need.
I wonder if you'll also scoff when people start asking for Copilot or GPT.
No autocomplete is a major pain in the ass when you use different languages and forget if it's "#list", "len(list)","list.len()", "list.length()", "list.size()" or "list.length".
Also, grug hit dot on keyboard and list of things grug can do pop up magic
Exackery. I seriously struggle when I'm using vim or nano on a remote box because they don't have autocomplete and I have to duckgo the syntax for bash. Bob help us all if I have to work in C++ like that with the 200 million variations on collection.add(). {eugh dunno}
Myself I am guilty of freaking out a candidate because I had just rolled off a huge escalation, heart racing and firing on all cylinders. Nervous, talking fast, etc.
I will try some Gotcha type questions to use as shorthand for how deep they are in certain areas. Even if someone whiffs one of those I am still likely to recommend them if everything else was good. No biggie. If there is time I will explain the answer to see how they digest it.
I am not trying to be an asshole. But in comparison I know a guy who won't hire someone if he doesn't like their shoes. He's an asshole outside of interviews though.
Your not an asshole like your friend. But it sounds like you are not an A player hiring other A players. What you are doing is going to net you a C or worse.
Put yourself in an A players shoes. Your trivia on the spot question shows you value unimportant things. A players can see talent in small signals and can map out a candidates profile you are trying to filter candidates by nonsense that doesn't map to the job. That leads to random results.
Hiring is an important management responsibility that most developers should not be involved with unless they are part of the management track hopefully with some training
> Hiring is an important management responsibility that most developers should not be involved with unless they are part of the management track
Absolutely, this is what it boils down to. After a certain point (like 15-20 engineers or so) you need someone in management to actually come up with an interview plan. Letting developers just wing interviews and ask trivia questions is a sign of an immature organization and is a big red flag for anyone senior coming in.
But the tech industry interview process is such low hanging fruit for mocking, I don't think this article is anything more than meme-ing a trendy topic for clicks.
If we really want to evolve into something better, then here's what I propose: All employers must release their laptop surveillance data to the public domain for all the see. That way we can objectively compare who writes the most LoC and logs the most onscreen hours.
I'm not sure what it was but I really disliked the style of this article. I felt like it was very light on actual examples. It would've been much more engaging if they had provided specific details on each of the mistakes that they, as an interviewer, had made.
As an interviewer, I prefer to give potential applicants a softball, like writing a function that computes the nth digit of PI in O(1).
me: [scans resume] ... "tell me about project y here"
interviewee: [tells me a bit]
me: [ask questions, listen, drill down, listen, get gently more and more technical, back off if I hit a soft spot and find another place to drill down]
repeat, repeat.
I find its a good way to determine the candidate's strengths - versus freaking them out with a gotcha that's irrelevant to their skillset.
I never had the misfortune to encounter such interviewing techniques nor had to use them on others. This is in two Fortune 500 companies and few smaller businesses.
Perhaps because I always interviewed for "full stack" jobs where the knowledge of tiny details this very moment is a lot less important than the ability to understand systems as a whole and how those little things fit together.
On the hiring end before it came to me being directly involved the candidate would already have gone through the basic "test" I and my colleagues prepared. It was a series of "question" "answer" sets starting with really simple and increasing in difficulty we gave to our manager. He would do the first part of the interview with a candidate and to fail, one would have to really have no clue. It was really surprising that 90% of candidates, with really good resumes we got sent by recruitment agencies failed that. It is important to stress those were not questions of the sort "implement some algorithm in pseudo language", but more like, "explain what is a microservice", "what is redis and when you would use it(assuming they have it in their cv)" etc. They were simple questions. I had similar questions on every single interview asked of me when I was a candidate (except the very first one when I was asked to fix an actual issue, but by then I was almost hired).
Then once they passed this initial step they would sit down with us(hopefully their future coworkers) and we would talk to them about their resume, ask what they worked at in previous jobs, what problems they resolved and how etc. This allowed me and my coworkers doing that part of the interview to very quickly get an idea if the person we're interviewing is on "our level" or not. Perhaps it was helpful that we interviewed people for both senior and junior positions so someone with less experience, but demonstrating ability/willingness to learn could still be a good match. At the end, if our manager was happy with what he heard he would ask us for our opinion. And I have to say, despite this easy-going interview method it took us over a year to find a good candidate for one senior role we were hiring for. During this year we had only 5 or 6 people progress to the second stage and we had a new stack of CVs to go through every 2 weeks or so. We did get 3 people for junior roles at the same time.
So is it true "most people interviewing have no clue"? I'll respond to this by saying it depends which recruiter has sent them. I have had recruiters admit to me they "tweak" CVs on more than one occasion. Also, yes, there are lots of people applying for jobs way above their skill level. Hiring is not easy. That's why good recruiters make more money than developers they recruit (I know a recruiter making £50k monthly in commission).
1. What do you do for fun when not at work? … dig into to questions from here. 2. What is the coolest thing you ever built? How did it work? How long did it take to build? What language? What architecture / framework? What was hard about it? … you get the idea. 3. What are your biggest pet peeves when it comes to reading other peoples code?
Question #1 breaks the ice and gives permission to the candidate to be themselves. Look for common ground. Connect with them. Learn who they are as a person.
Question #2 gets you to see their passion. Talk to them on their ground. Give them the benefit of the doubt. Ask them hard questions, but don’t intimidate. Just go deep. The candidate cannot fake this. It’s not possible. People without the experience they claim are painfully obvious here.
Question #3 gives you two things. 1. Is this person openly critical of things looking to improve them? And Is this person a jerk? I call this the Jerk Trap. Jerks jump right in to being Jerks. After all you just kind of game them permission here! — I would ask though you be careful about excluding neurodiverse people who may not be able to control tone or navigate social situations well. These people will tend to be direct. Don’t confuse directness with being a Jerk. They are not the same thing.
I’ve interviewed a lot of engineers in my career, and tried a lot of things. This methodology has yet to fail me.
EDIT: It’s sad I even have to point this out, but in #1 you are looking to connect with the person on a human level. It’s not bait them into talking about coding outside of work. If you do that or think that way you are being discriminatory towards people who can’t code outside of work… you know like single mothers. And people wonder why we don’t have more women in tech. Stop equating passion with > 40 hours a week. It’s bullshit. Stop.