Is The Modern Technical Interview Flawed For Software Engineer Candidates?

EJS · Jan 2, 2021

I feel like I have been making a decent amount of coding questions here, but I think this one has been on my mind for some time.

Do you think the modern technical interview for open Software Engineer roles is broken? When I say modern, I mean questions that you typically find on LeetCode and the like or extensive whiteboard problems via online software or in-person.

If you are not familiar with LeetCode or a similar service - it's basically a collection of problems that you solve through code. These questions vary in difficulty and can be filtered on specific companies that might be likely to ask such questions on an interview.

If you browse the Discussion section of LeetCode, you will find people sharing their stories of how they trained for months, sometimes years to prepare for their interview. Of course, not all are successful, as there are often more failure stories than success.

It felt like only FAANG companies would use LeetCode to identify candidates but it seems like a lot more companies are taking this approach as well.

Personally, I am mixed on the modern technical interview. I think candidates who cannot solve a BFS problem on the fly should not be discarded because I know that 9 times out of 10, the person issuing the question couldn't either. However, some level of assessment should be considered. I think a lot of companies put too much emphasis on reversing a Linked List or designing a LRU Cache and do not consider candidate's previous work and contributions or how they would gel with the team, given their personality.

I think a fair interview would be to give a candidate a crude version of a bug that exists in their backlog (not exact, but the gist) and to let the candidate use any resource they can to solve it (while watching them and asking their approach). I'd let them Google and would evaluate their searches and their thought process, rather than the code so much. Maybe that makes me soft, but that's how 99% of developers work anyway. No one has merge sort memorized.

Also, I don't think companies realize or care how demoralizing a bad interview can go for candidates. If I get a question you just don't understand, I start to get self-doubt and down on myself. It makes me feel worthless, to be honest. I can't talk my way through it - I just look and feel not so smart.

Anyway, what do you all think? Is it survival of the fittest or has the modern technical interview evolved into something that is not a true measure of a good candidate?

Davidion · Jan 2, 2021

It's generally agreed that almost all interview processes are subject to Sturgeon's Law. But I think it's worse in technology, particularly human-facing ones.

I'm a UXD, but IMO there's a common phenomenon in dev/design/product where companies don't understand that it's complex system work. Typically, they need to have a blend of hard execution, soft collab, and learning/adaptation skills over time. But where they don't have all of these things working well together, they'll try to use elaborate upfront acrobatics and process cruft to compensate for their inability to make good judgement at scale, especially unnecessarily complicated execution challenges.

There's a metaphor for many/most organizations' incompetency at manage good development/design/product processes somewhere in here. The cause is the fact that they can't manage good processes of sharing understanding, and the symptom is overreliance on sellable artifacts and vanity metrics.

Labyrinthe · Jan 2, 2021

IT is really vast but when you know your stuff it's really easy to spot imposters.

When i managed a team, i was told i asked to many hard technical questions and by boss was scared this would give a bad image of the company to the candidate (since we had headhunters searching for us). The result is that the candidates we had to choose where not up for the challenge and where not reliable...

So yeah i agree, the whatever the method used for IT interview is pretty much useless. You also have people that don't have the knowledge but are really good at learning fast and end up really good candidates if you give them the resources and time to evolve.

My interviews where pretty much personality tests since technically i was always head and shoulders above the requirements.

Brandino · Jan 2, 2021

A lot of the programming questions I've been asked for interviews are usually nothing I've come across in real world. I swear, some of them are hard just to be hard.

The time constrains can be annoying too.

Deleted member 46493 · Jan 2, 2021

The issue is not that there's no perfect interview process. You can try white board, take-home project, just talking, focus on experience, etc. There's pros and cons for all of them.

I did a few interviews in the fall and I wasn't asked any LeetCode questions - I did a take home project in one company and a lot of short "practical problem solving" at another, which I enjoyed.

--

The issue for me is that the interview process is way too long. Every company at some point wants five or more hours of your time to grill you with three to four separate interviews. That's AFTER a few hours of prelim interviews or a take home project. And after all that you may still get a once sentence email that it didn't work out.

strang · Jan 2, 2021

I'm back in university for a second degree in computer science. It really seems like for internships and new grad jobs, grinding questions on Leetcode is the single most important thing for me to be doing with my time. More important than studying and doing well in classes and more important than working on personal projects or going to hackathons (which also seem necessary but definitely not sufficient.) I haven't done any technical interviews yet, but that in and of itself seems kind of broken to me.

Deleted member 46493 · Jan 2, 2021

strang said:
I'm back in university for a second degree in computer science. It really seems like for internships and new grad jobs, grinding questions on Leetcode is the single most important thing for me to doing with my time. More important than studying and doing well in classes and more important than working on personal projects or going to hackathons. I haven't done any technical interviews yet, but that in and of itself seems kind of broken to me.

Was the same in 2016 when I graduated. Was never asked about projects or hackathons. Only LeetCode/whiteboard and maybe internship experience.

spam musubi · Jan 2, 2021

It depends on the company size, culture etc. Larger companies get way too many applicants and need to have a standardized process that tries to eliminate bias in some ways (but it's just a matter of what biases you pick and choose). In smaller companies it can be pretty ad-hoc. There is no perfect process, but the real problem is when teams use a process that doesn't necessarily mesh well with their culture and style of work and ask questions that aren't useful to judge a candidate. In the end it's a supply/demand issue as well, the company has one slot to fill and a hundred applications for the slot, so even if their interview is way too grueling, they can just pick the person who did the best. Whereas an applicant will spend so much time and energy trying to get into that slot. You have to think from the perspective of the employer when trying to understand whether the interview process is good or not. The process is likely to be unpleasant for applicants no matter what because there is so much competition.

Z1r2y3 · Jan 2, 2021

Current programming and IT interviews are absolute shit especially if they are copying FAANG methods. Mainly because some of the stuff is simply not practical.

IT and computer science is the one area I feel like people are severely underpaid and under appreciated.

Your company expects you to spend your off time expanding your knowledge for no pay and expects you to be on call 24/7. The tech world is absolute shit.

tokkun · Jan 2, 2021

As someone who has given plenty of these interviews at a FAANG company, let me correct a couple common misconceptions:

When you talk about "companies" deciding what questions to ask, it makes it sound like it is some kind of well-organized, top-down process. In fact it is quite the opposite. I may be told "give a coding interview" or "give a design interview", but the rest is up to me. I make up my own questions and question format. The only control the company exerts is that there is a database of banned questions we are not allowed to ask. We do get training for giving interviews, but the training is mostly focused on understanding the legal issues and things like unconscious bias. There is very little training on "this is how you design a question."

If this makes you wonder why the questions and formats all seem to be so similar, it is because people draw on their own experience. Most people are used to taking tests in school, and so their interview looks like part of an exam from a university class.

The other misunderstanding I run into a lot is in how candidates view the purpose of the questions. For the candidate, it is usually all about getting the "right answer", because again - that is what people are used to from school. However, I actually care very little about the final answer. I ask questions as an icebreaker to get the candidate to talk me through their thought process and their problem solving methods. I do not want the candidate to be able to slam out a solution in 60 seconds like it is a LeetCode exercise, because I learn very little from that, other than that they have practiced and memorized a lot. I learn a lot more about the candidate when I give them a question that they initially have no idea how to solve at first.

spam musubi · Jan 2, 2021

tokkun said:
As someone who has given plenty of these interviews at a FAANG company, let me correct a couple common misconceptions:

When you talk about "companies" deciding what questions to ask, it makes it sound like it is some kind of well-organized, top-down process. In fact it is quite the opposite. I may be told "give a coding interview" or "give a design interview", but the rest is up to me. I make up my own questions and question format. The only control the company exerts is that there is a database of banned questions we are not allowed to ask. We do get training for giving interviews, but the training is mostly focused on understanding the legal issues and things like unconscious bias. There is very little training on "this is how you design a question."

If this makes you wonder why the questions and formats all seem to be so similar, it is because people draw on their own experience. Most people are used to taking tests in school, and so their interview looks like part of an exam from a university class.

The other misunderstanding I run into a lot is in how candidates view the purpose of the questions. For the candidate, it is usually all about getting the "right answer", because again - that is what people are used to from school. However, I actually care very little about the final answer. I ask questions as an icebreaker to get the candidate to talk me through their thought process and their problem solving methods. I do not want the candidate to be able to slam out a solution in 60 seconds like it is a LeetCode exercise, because I learn very little from that, other than that they have practiced and memorized a lot. I learn a lot more about the candidate when I give them a question that they initially have no idea how to solve at first.

This. But depending on the company they might have question banks you are supposed to select from.

Davidion · Jan 2, 2021

tokkun said:
As someone who has given plenty of these interviews at a FAANG company, let me correct a couple common misconceptions:

When you talk about "companies" deciding what questions to ask, it makes it sound like it is some kind of well-organized, top-down process. In fact it is quite the opposite. I may be told "give a coding interview" or "give a design interview", but the rest is up to me. I make up my own questions and question format. The only control the company exerts is that there is a database of banned questions we are not allowed to ask. We do get training for giving interviews, but the training is mostly focused on understanding the legal issues and things like unconscious bias. There is very little training on "this is how you design a question."

If this makes you wonder why the questions and formats all seem to be so similar, it is because people draw on their own experience. Most people are used to taking tests in school, and so their interview looks like part of an exam from a university class.

The other misunderstanding I run into a lot is in how candidates view the purpose of the questions. For the candidate, it is usually all about getting the "right answer", because again - that is what people are used to from school. However, I actually care very little about the final answer. I ask questions as an icebreaker to get the candidate to talk me through their thought process and their problem solving methods. I do not want the candidate to be able to slam out a solution in 60 seconds like it is a LeetCode exercise, because I learn very little from that, other than that they have practiced and memorized a lot. I learn a lot more about the candidate when I give them a question that they initially have no idea how to solve at first.

All of this.

EJS · Jan 2, 2021

tokkun said:
As someone who has given plenty of these interviews at a FAANG company, let me correct a couple common misconceptions:

When you talk about "companies" deciding what questions to ask, it makes it sound like it is some kind of well-organized, top-down process. In fact it is quite the opposite. I may be told "give a coding interview" or "give a design interview", but the rest is up to me. I make up my own questions and question format. The only control the company exerts is that there is a database of banned questions we are not allowed to ask. We do get training for giving interviews, but the training is mostly focused on understanding the legal issues and things like unconscious bias. There is very little training on "this is how you design a question."

If this makes you wonder why the questions and formats all seem to be so similar, it is because people draw on their own experience. Most people are used to taking tests in school, and so their interview looks like part of an exam from a university class.

The other misunderstanding I run into a lot is in how candidates view the purpose of the questions. For the candidate, it is usually all about getting the "right answer", because again - that is what people are used to from school. However, I actually care very little about the final answer. I ask questions as an icebreaker to get the candidate to talk me through their thought process and their problem solving methods. I do not want the candidate to be able to slam out a solution in 60 seconds like it is a LeetCode exercise, because I learn very little from that, other than that they have practiced and memorized a lot. I learn a lot more about the candidate when I give them a question that they initially have no idea how to solve at first.

This some good insight. Sorry if I sounded ignorant in my post - didn't mean that.

Threadkular · Jan 2, 2021

So one thing that's kind of interesting with this is if you interview for a software engineering job in the US "aerospace" industry there's hardly if any ever technical questions and rather more of the questions about experience and how you work in a team, etc. Out of college GPA is looked at very highly.

The negative side is you can get some absolute whiffs on candidates that get in in regards to technical skill. Looking at a place like Google or Amazon's process, I would have to think it be near impossible for some one to fake their knowledge on a subject when so explicitly tested. I'm a technical person so if I were running a company I'd probably lean more towards the formal testing process.

The other big thing is the FAANG and the like have the ability to be as selective as they want because they're so desired. If they ever lose that, then they'd change their practices, but why should they if they don't need to? I mean I want to complain about their interview testing processes but truthfully that's because I'm not up to snuff to pass them. I graduated top of my engineering class too but those type of questions are just out of my ability typically, at least on the spot.

cubicle47b · Jan 2, 2021

Yeah, I think it's flawed, especially for the type of application development I've done for the majority of my career. There have been very few situations where I've really had to optimize code or write a truly difficult algorithm. You need a certain amount of technical ability/knowledge to do the job, but there's a lot more to being a good developer. Working well with the rest of the development team, understanding customer needs and building strong relationships with them, finding/choosing the right tools for the job, the ability to learn new things quickly, etc.

edit:

I think this is my company's current process for hiring a developer.
- 30 minute phone interview with the company owners (who are developers) to get to know the candidate, their experience level, and career goals
- 1 hour in-person interview with the company owners
- Take home technical exercise done in a language of their choice, based on a real-world problem, that should only take a few hours
- Paid pair programming session with one of our technical leads

TarpitCarnivore · Jan 2, 2021

I had the best technical 1on1 interview recently.

I was on a video call with CodePen open and the question was "Subtract two numbers with only addition" or something like that. And the entire thing was geared around collaborative peer programming. So I would start something or the would start and then just keep alternating, and riffing. Obviously they have the solution but the entire goal was to see how you would do actually working out a problem together.

Tater · Jan 2, 2021

tokkun said:
The other misunderstanding I run into a lot is in how candidates view the purpose of the questions. For the candidate, it is usually all about getting the "right answer", because again - that is what people are used to from school. However, I actually care very little about the final answer. I ask questions as an icebreaker to get the candidate to talk me through their thought process and their problem solving methods. I do not want the candidate to be able to slam out a solution in 60 seconds like it is a LeetCode exercise, because I learn very little from that, other than that they have practiced and memorized a lot. I learn a lot more about the candidate when I give them a question that they initially have no idea how to solve at first.

Former hiring manager here - tokkun is absolutely right. When doing a test like this, I don't care if the candidate gets the right answer. I'm imagining what it will be like to work with this person on day to day basis. Do they take criticism well? Can they handle a curveball? Although basic competency is important, you wouldn't believe how many people I've seen struggle on FizzBuzz.

I personally think some of these programming gauntlets are ridiculous, though - I'm looking around right now, and it's just a pain in the ass to have to study up for a job I'm already doing full time.

Z1r2y3 · Jan 2, 2021

tokkun said:
As someone who has given plenty of these interviews at a FAANG company, let me correct a couple common misconceptions:

When you talk about "companies" deciding what questions to ask, it makes it sound like it is some kind of well-organized, top-down process. In fact it is quite the opposite. I may be told "give a coding interview" or "give a design interview", but the rest is up to me. I make up my own questions and question format. The only control the company exerts is that there is a database of banned questions we are not allowed to ask. We do get training for giving interviews, but the training is mostly focused on understanding the legal issues and things like unconscious bias. There is very little training on "this is how you design a question."

If this makes you wonder why the questions and formats all seem to be so similar, it is because people draw on their own experience. Most people are used to taking tests in school, and so their interview looks like part of an exam from a university class.

The other misunderstanding I run into a lot is in how candidates view the purpose of the questions. For the candidate, it is usually all about getting the "right answer", because again - that is what people are used to from school. However, I actually care very little about the final answer. I ask questions as an icebreaker to get the candidate to talk me through their thought process and their problem solving methods. I do not want the candidate to be able to slam out a solution in 60 seconds like it is a LeetCode exercise, because I learn very little from that, other than that they have practiced and memorized a lot. I learn a lot more about the candidate when I give them a question that they initially have no idea how to solve at first.

I mean this is kinda still bullshit no matter how you try to make it acceptable. No other jobs do this kinda BS.

Irnbru · Jan 2, 2021

tokkun said:
As someone who has given plenty of these interviews at a FAANG company, let me correct a couple common misconceptions:

When you talk about "companies" deciding what questions to ask, it makes it sound like it is some kind of well-organized, top-down process. In fact it is quite the opposite. I may be told "give a coding interview" or "give a design interview", but the rest is up to me. I make up my own questions and question format. The only control the company exerts is that there is a database of banned questions we are not allowed to ask. We do get training for giving interviews, but the training is mostly focused on understanding the legal issues and things like unconscious bias. There is very little training on "this is how you design a question."

If this makes you wonder why the questions and formats all seem to be so similar, it is because people draw on their own experience. Most people are used to taking tests in school, and so their interview looks like part of an exam from a university class.

The other misunderstanding I run into a lot is in how candidates view the purpose of the questions. For the candidate, it is usually all about getting the "right answer", because again - that is what people are used to from school. However, I actually care very little about the final answer. I ask questions as an icebreaker to get the candidate to talk me through their thought process and their problem solving methods. I do not want the candidate to be able to slam out a solution in 60 seconds like it is a LeetCode exercise, because I learn very little from that, other than that they have practiced and memorized a lot. I learn a lot more about the candidate when I give them a question that they initially have no idea how to solve at first.

its this (from my BI/SQL perspective)

tokkun · Jan 2, 2021

Zhou said:
This some good insight. Sorry if I sounded ignorant in my post - didn't mean that.

It's completely reasonable for someone without inside experience to expect that things would be more organized and less chaotic. I have often lamented the fact that we don't have a group of trained professionals who are experts at interviewing giving these interviews rather than rank and file engineers, but it is sort of a cultural thing.

FWIW, things are exactly the same way in academia. You get like maybe 3 days of formal training before they throw you into a college classroom as a TA or professor, but I don't think most university students get that either.

Z1r2y3 · Jan 2, 2021

Tater said:
I personally think some of these programming gauntlets are ridiculous, though - I'm looking around right now, and it's just a pain in the ass to have to study up for a job I'm already doing full time.

I hope I don't have to go through the hiring process again but the next time I'll just whip out my phone and look up the answers, which is the exact same method the interviewers used to formulate these Ridiculous questions.

just_myles · Jan 2, 2021

cubicle47b said:
Yeah, I think it's flawed, especially for the type of application development I've done for the majority of my career. There have been very few situations where I've really had to optimize code or write a truly difficult algorithm. You need a certain amount of technical ability/knowledge to do the job, but there's a lot more to being a good developer. Working well with the rest of the development team, understanding customer needs and building strong relationships with them, finding/choosing the right tools for the job, the ability to learn new things quickly, etc.

I agree with this. It is flawed. Especially since I know that they probably won't be doing anything like that once/if they're hired. For me, I didn't learn anything until I was on the job. Out of school I really didn't know anything and it wasn't until I got my first job in IT that I started to actually learn. I worked with a difficult team at times but they were always good about being mentors and teaching. I think that is the most important thing especially for juniors coming out of college. I wouldn't judge too harshly if they couldn't solve a complex problem or tell me what a pointer is. I want to know how you will fit in with the team. From a technical perspective I would want to see your approach to handling problems. Not so much about being right or wrong.

I think that kind of hiring practice at FAANGS creates a certain type of rigidity in their candidate selection. Some of the best programmers I have ever worked with did not start out that way and did not go to top rated colleges or college at all.

Threadkular · Jan 2, 2021

Z1r2y3 said:
I hope I don't have to go through the hiring process again but the next time I'll just whip out my phone and look up the answers, which is the exact same method the interviewers used to formulate these Ridiculous questions.

Just a little self awareness check... my wife and I interview candidates and it's always obvious when people are doing this. That is of course, obvious to everyone except the interviewee doing it. You'll be in your head thinking you nailed it and the interviewer will be super insulted you think he/she is an absolute moron.

turbobrick · Jan 2, 2021

As someone who recently graduated with a CS degree and is trying to get a programming job, I'm dreading interviews and the random questions I'll have to answer.

Z1r2y3 · Jan 2, 2021

Threadkular said:
Just a little self awareness check... my wife and I interview candidates and it's always obvious when people are doing this. That is of course, obvious to everyone except the interviewee doing it. You'll be in your head thinking you nailed it and the interviewer will be super insulted you think he/she is an absolute moron.

I won't be trying to hide it. My explanation would be this would be the faster and more efficient method in solving the problem. It'll save time and cost.

Threadkular · Jan 2, 2021

Z1r2y3 said:
I won't be trying to hide it. My explanation would be this would be the faster and more efficient method in solving the problem. It'll save time and cost.

Fair enough. I hope the interviewer finds that as clever as you do.

SeanBoocock · Jan 2, 2021

Any interview process will have tradeoffs. I have experienced most - take home tests, take home projects, live (un)timed tests, live interactive programming, whiteboard exercises, debugging exercises, written exams - as both an interviewer and interviewee.

To give you some perspective, as someone that is looking to hire engineers, I have to be able to efficiently filter and estimate candidate's aptitude for a given role. Any given position will have hundreds of resumes, out of which there will be tens of people who are good prospective candidates. I want to:

Assess each candidate's skills and experience in a repeatable and objective way
Respect the candidate's time
Filter candidates such that only those that are best matched for the position are interviewed by the whole team

Giving candidate's a test or sample project to implement with a long lead time (say a week), seems attractive in terms of alleviating the anxiety that can often come up in a live interview setting. The tradeoff there is that it doesn't respect the candidate's time, and privileges people who are in a situation where they can devote more time to the test than others. It also, at least in my experience, does not correlate that well with job performance. One axis that differentiates programmers is productivity and the differences can be quite stark; a (loosely timed) test masks that.

Whiteboard exercises (and their digital analogues) aren't the sorts of things you will be doing as a software engineer, but they can reveal your capability to solve problems. How well do you understand the scope of the problem? How well do you communicate your thought process? Do you work methodically and logically towards a potential solution? To take one example, I don't care about "reversing a linked list". I care about whether you can solve "reversing a linked list" complexity problems, communicate your thought process in developing a solution, and express the solution in code.

There are all sorts of problems with whiteboard exercises - potential systemic bias depending on how it is conducted; testing against people who respond poorly to the anxiety induced by those interviews - but it seems the least bad of poor options to assess skill. It is also less important the more senior someone is as their experience becomes a bigger signal of their capabilities.

ChrizzSTARR · Jan 2, 2021

I luckily got out of the interview phase pretty quick and got into the industry without having to go through these stupid LeetCode puzzles, but my take is this:

How many problems have I solved by having an understanding of how systems and APIs interact? Dozens, hundreds even.

How many LeetCode questions could I answer on the spot? Probably 0.

Which should matter to an employer?

Now I understand that as someone with experience, I'll be looked at differently than a fresh college grad, but even in the case of someone with no experience, these questions should not make or break a candidates chances.

voidecker · Jan 2, 2021

I've posted this video a few times in threads like these before, but it really helped put things into perspective for me when I was interviewing earlier this year

Coding Interviews are Broken

Algorithm style coding interviews are very common in the tech industry, but they are a crappy method to evaluate candidates. Might work well for FANG (Facebo...

youtu.be

TarpitCarnivore · Jan 2, 2021

Tater said:
Former hiring manager here - tokkun is absolutely right. When doing a test like this, I don't care if the candidate gets the right answer. I'm imagining what it will be like to work with this person on day to day basis. Do they take criticism well? Can they handle a curveball? Although basic competency is important, you wouldn't believe how many people I've seen struggle on FizzBuzz.

I personally think some of these programming gauntlets are ridiculous, though - I'm looking around right now, and it's just a pain in the ass to have to study up for a job I'm already doing full time.

The problem is many of the questions asked down allow for that level of feedback loop and back and forth, and in some cases the people doing them are awful at it.

There's better ways to do this without relying on memorization of leetcode problems.

CthulhuSars · Jan 2, 2021

It is situational. Some interviews I feel need a process that involves how a person thinks even if they get the problem wrong. I find it more useful how the candidate answers the question or asks questions about the question to better understand how to try to answer the question than a correct answer. I actually push harder for panel interviews based on technical questions mixed on what the candidate put on the resume/CV to test the bullshit meter more than if the candidate can actually correctly answer loaded hard programming questions. If in a panel interview situation the group is satisfied with the interview and can gauge how the person thinks often skip the stupid loaded hard questions to suss out the individuals way of problem solving.

Angelus Errare · Jan 2, 2021

tokkun said:
As someone who has given plenty of these interviews at a FAANG company, let me correct a couple common misconceptions:

When you talk about "companies" deciding what questions to ask, it makes it sound like it is some kind of well-organized, top-down process. In fact it is quite the opposite. I may be told "give a coding interview" or "give a design interview", but the rest is up to me. I make up my own questions and question format. The only control the company exerts is that there is a database of banned questions we are not allowed to ask. We do get training for giving interviews, but the training is mostly focused on understanding the legal issues and things like unconscious bias. There is very little training on "this is how you design a question."

If this makes you wonder why the questions and formats all seem to be so similar, it is because people draw on their own experience. Most people are used to taking tests in school, and so their interview looks like part of an exam from a university class.

The other misunderstanding I run into a lot is in how candidates view the purpose of the questions. For the candidate, it is usually all about getting the "right answer", because again - that is what people are used to from school. However, I actually care very little about the final answer. I ask questions as an icebreaker to get the candidate to talk me through their thought process and their problem solving methods. I do not want the candidate to be able to slam out a solution in 60 seconds like it is a LeetCode exercise, because I learn very little from that, other than that they have practiced and memorized a lot. I learn a lot more about the candidate when I give them a question that they initially have no idea how to solve at first.

This is the correct approach to hiring, sadly it's not the universal approach and it's depressing. I've seen so many amazing developers get rejected because they weren't able to successfully solve their interview problems. Like when I do interviews, sure you can spit out a BST from memory but I'd rather see someone go through their problem solving/process of elimination even if they can't actually create the BST. "I don't know" is a perfectly fine answer for me, because I'm more looking at are the making small notes of the problem I presented to them? What do they know of BST? Can they explain/guessimate what/how a BST would work?

Far too often you have developer interviews where it's like hey create a BST, implement DFS/BFS in like 10 mins. And don't get me wrong I don't want someone who is clueless on what these things are, but I won't lie most of the time we're never going to have to have anyone implement one from scratch but it's invaluable to know of the various data structures and algorithms. There's a line that I feel far far too many interviews lean towards someone one who can regurgitate book knowledge than someone who may not be able to implement on the drop of the dime but they have great problem solving skills even if aforementioned skills are slow to get to the end point.

Also we have too many damn companies looking for "10x developer ninja!" whatever the fuck that even means.

strang · Jan 2, 2021

tokkun said:
The other misunderstanding I run into a lot is in how candidates view the purpose of the questions. For the candidate, it is usually all about getting the "right answer", because again - that is what people are used to from school. However, I actually care very little about the final answer. I ask questions as an icebreaker to get the candidate to talk me through their thought process and their problem solving methods. I do not want the candidate to be able to slam out a solution in 60 seconds like it is a LeetCode exercise, because I learn very little from that, other than that they have practiced and memorized a lot. I learn a lot more about the candidate when I give them a question that they initially have no idea how to solve at first.

Correct me if I'm wrong because obviously you're the one with the experience here. Everyone I've talked to about technical interviews has said exactly this, but also that at the end of the day at least for new grads and internships, to do well on these types of questions you need to do lots of practice on these types of questions. To the point where it almost seems like everything else about learning CS in school is incidental to just practicing interview questions.

Z1r2y3 · Jan 2, 2021

Threadkular said:
Fair enough. I hope the interviewer finds that as clever as you do.

I don't think it's creative but it is realistic.

NetMapel · Jan 2, 2021

tokkun said:
As someone who has given plenty of these interviews at a FAANG company, let me correct a couple common misconceptions:

When you talk about "companies" deciding what questions to ask, it makes it sound like it is some kind of well-organized, top-down process. In fact it is quite the opposite. I may be told "give a coding interview" or "give a design interview", but the rest is up to me. I make up my own questions and question format. The only control the company exerts is that there is a database of banned questions we are not allowed to ask. We do get training for giving interviews, but the training is mostly focused on understanding the legal issues and things like unconscious bias. There is very little training on "this is how you design a question."

If this makes you wonder why the questions and formats all seem to be so similar, it is because people draw on their own experience. Most people are used to taking tests in school, and so their interview looks like part of an exam from a university class.

The other misunderstanding I run into a lot is in how candidates view the purpose of the questions. For the candidate, it is usually all about getting the "right answer", because again - that is what people are used to from school. However, I actually care very little about the final answer. I ask questions as an icebreaker to get the candidate to talk me through their thought process and their problem solving methods. I do not want the candidate to be able to slam out a solution in 60 seconds like it is a LeetCode exercise, because I learn very little from that, other than that they have practiced and memorized a lot. I learn a lot more about the candidate when I give them a question that they initially have no idea how to solve at first.

In my experience, I think interviewers do tend to make it clear that they are more interested in the person's thought process than the final answer. However, some "LeetCode" type questions feel very gamey and so a candidate would be tempted to just reach for the solution instead of walking through their thought process. In fact, if you really want my thought process if I were to tackle the question blindly, I would say that I'd probably google it :P I have never tried to answer a question like that but I'm starting to be tempted to if I want to be completely honest to the interviewer. So I guess what I'm trying to say is, my hope is that the questions are also designed to incentivize the candidate to walk through their thought process. It also depends on the role that one is hiring. The quality of the questions matter as the candidate are looking for guidance and clue on how they should proceed next in during the interview process. I personally favour more communication-style interviews because of it. I can give past examples and talk through how I tackled xyz issues from experience. But if I'm being given a brand new leetcode-style problem that I have to tackle, my thought process basically jumps to "ask around others" or "google it", which I don't think is what interviewers are really looking for anyways despite the realism of it.

TarpitCarnivore · Jan 2, 2021

strang said:
Correct me if I'm wrong because obviously you're the one with the experience here. Everyone I've talked to about technical interviews has said exactly this, but also that at the end of the day at least for new grads and internships, to do well on these types of questions you need to do lots of practice on these types of questions. To the point where it almost seems like everything else about learning CS in school is incidental to just practicing interview questions.

It's not just new grads fwiw

It's a dual edged sword because you need to validate their technical competency but the relaxed nature of it is often not conveyed. Further it doesn't help that shit like Leetcode exists to further drive this negative aspect

Deleted member 2809 · Jan 2, 2021

Never had one but I know they're bollocks

The Albatross · Jan 2, 2021

Yes. In 10 years I've interviewed .... 40 software engineers, and I've found no link between people being able to answer brain teasers and their effectiveness in a role. I used to justify it... 'well we just want to see how you think about a problem....not necessarily getting it right," but
... That's bullshit. I've seen too many people get rejected by some anal asshole for some gotcha bullshit that we all know *only* because we're in the interviewing role.

And y'know plenty of people we've hired haven't worked out at any greater or lesser rate.

I think for junior developers it might be tough. But for senior or experience devs, if you've produced something then you can probably work thru real problems.

Also 98% of my work as a senior software engineer is easier than the brain teasers in interviews. And like 50% of my work is dragging stories along a board in jira. Requires 0 technical experience.

Chikor · Jan 2, 2021

Zhou said:
No one has merge sort memorized.

I do, but it's 100% because of interviews.
I generally agree with you, the questions that they ask at interviews are just not great, at most they can filter people who are lying about ever coded, but that's about it, and they filter out a whole lot of good people too.
It mostly reward practicing those type of questions and punish a whole lot of unrelating traits like being uncomfortable public speaker.

steejee · Jan 2, 2021

cubicle47b said:
Yeah, I think it's flawed, especially for the type of application development I've done for the majority of my career. There have been very few situations where I've really had to optimize code or write a truly difficult algorithm. You need a certain amount of technical ability/knowledge to do the job, but there's a lot more to being a good developer. Working well with the rest of the development team, understanding customer needs and building strong relationships with them, finding/choosing the right tools for the job, the ability to learn new things quickly, etc.

edit:

I think this is my company's current process for hiring a developer.
- 30 minute phone interview with the company owners (who are developers) to get to know the candidate, their experience level, and career goals
- 1 hour in-person interview with the company owners
- Take home technical exercise done in a language of their choice, based on a real-world problem, that should only take a few hours
- Paid pair programming session with one of our technical leads

This is not far off my own process. Myself and two others do in person (now phone) interviews that are 1o1 and around 30m each. I usually start with an intro to the company from my perspective then go through their resume with them focusing on relevant experience. I mostly try to get them to just talk about tech, ups and downs of their career, what they hope to do going forward and what they're looking for in their next job. In other words I orient it to be a conversation rather than a grilling.

I never do any sort of whiteboard type quiz or question, it's just not helpful to me.

If we all think someone is a good candidate after the three of us talk to them, we send them an at home exam. Basically give them a requirement list for implementing a public API and a time limit. We record the session (our company does online proctoring, so this allows them to do it whenever they want) and ask that at the time limit they submit whatever they did - the requirements list is too big to do in the time limit on purpose. From there we can get a picture of their work process and output. They're told to use whatever tools and resources desired and given a vague outline of the requirements before starting.

So far everyone we've hired has matched the expectations we had for them based on this.

All told a candidate will probably spend 4-5h total on this process start to finish, with each step being a bit longer than the previous if they pass (< 30m initial screen, ~1.5h 1o1s, ~2.5h take home test). I think we pretty much always make an offer to anyone we give the exam to, it mostly acts to zero in what level of position we'd be hiring them for.

tokkun · Jan 2, 2021

strang said:
Correct me if I'm wrong because obviously you're the one with the experience here. Everyone I've talked to about technical interviews has said exactly this, but also that at the end of the day at least for new grads and internships, to do well on these types of questions you need to do lots of practice on these types of questions. To the point where it almost seems like everything else about learning CS in school is incidental to just practicing interview questions.

Practice inevitably helps people. Even if you try to design your assessment to be less dependent on practice, like with IQ tests or the SAT, you can't completely eliminate practice as a factor.

First, practicing something will make you more confident and less nervous, which will improve your overall mental state and performance. When you start to panic your body produces cortisol, which impairs learning and memory. If you're anything like me, you've had those situations where you were stumped on a problem during an exam, only to have the answer come to you as you are walking home afterward.

Second, the interview process is also testing soft skills like time management and communication. Some people are strong technically, but poor at organizing their thoughts and expressing their ideas to others because these are skills that also require practice to master.

The biggest problems I see from new grad applicants tends to be around these issues of managing ones' emotions when you don't know the answer to a question and communicating your thought process effectively. These are things you naturally get a lot of practice in when you do real world work, but schools tend to be pretty poor at cultivating. For these reasons I think the most useful type of practice is to do some mock interviews, rather than just doing tons of algorithms questions, but really any practice is better than none.

ToD_ · Jan 2, 2021

I wrote my one and only thread a few months ago regarding my anxiety of a job interview I was about to go into at the time. People responding in that thread were awesome, and it helped me a great deal. There was a typical leetcode question during the interview, which I worked on together with the interviewer with a time limit of ~30 minutes. I did alright, I suppose, but I did not get the job. Got the standard one line email saying they found a candidate with better qualifications.

Just a few weeks ago, I graduated from college with a degree in CS at age 39. I'm about to turn looking for jobs into a full-time job. Sadly, that means I'll be spending my time doing mostly leetcode type problems to prepare. I'm not sure if the system is flawed, but I sure dislike it. I did not know about the technical interviews before going in to college so I was a little surprised to learn about this partway into my degree. I hope with more interview experience I'll get better at these questions, and eventually land a job.

Tater · Jan 2, 2021

TarpitCarnivore said:
The problem is many of the questions asked down allow for that level of feedback loop and back and forth, and in some cases the people doing them are awful at it.

There's better ways to do this without relying on memorization of leetcode problems.

Totally agree. I'm not in a managerial role currently, but I still help out with interviews. At my current company, you have to shadow people a few times before interviewing someone, and there is a training program you have to go through if you want to be running part of the interview.

I don't work for a FAANG company, but I'm not kidding in that I start with FizzBuzz. You shouldn't need any preparation to handle that. If you can't do that and explain your answer, we end the interview early. For later problems, I try to make them fairly self contained, rather than relying on specific domain knowledge, or something that you would just look up in practice.

TarpitCarnivore · Jan 2, 2021

Tater said:
Totally agree. I'm not in a managerial role currently, but I still help out with interviews. At my current company, you have to shadow people a few times before interviewing someone, and there is a training program you have to go through if you want to be running part of the interview.

I don't work for a FAANG company, but I'm not kidding in that I start with FizzBuzz. You shouldn't need any preparation to handle that. If you can't do that and explain your answer, we end the interview early. For later problems, I try to make them fairly self contained, rather than relying on specific domain knowledge, or something that you would just look up in practice.

I mentioned earlier my most recent interview was perfect: subtract two numbers using only addition without using any built in libraries The person started the function and then I took over and we kept alternating.

Hands down the best technical interview I ever had because they never once let me hang in the wind. They were constantly saying "what are you thinking".

Tater · Jan 2, 2021

TarpitCarnivore said:
I mentioned earlier my most recent interview was perfect: subtract two numbers using only addition without using any built in libraries The person started the function and then I took over and we kept alternating.

Hands down the best technical interview I ever had because they never once let me hang in the wind. They were constantly saying "what are you thinking".

I like that, may have to steal that one. ;)

TarpitCarnivore · Jan 2, 2021

Tater said:
I like that, may have to steal that one. ;)

It was the perfect kind of back to basics. It's such a simple function and algorithm but you're likely working in such deeper stuff to wind the brain back is a few skips of a beat.

Whereas leetcode stuff is basics but in the worst possible way

btags · Jan 2, 2021

I am not a software engineer or anything but my partner is and this is what I would say about seeing her interview with leet ide problems and the like. I don't understand short term problems like that as it seems during normal work you would not have such time constraints (obviously still some) and you would be able to look up stuff to help you solve the problem. Also, from what I saw a lot of the stuff that comes up in these types of problems is nothing relevant to her type of work. So basically, it just becomes being a good test taker rather than showing how good you are at the actual work.

Additionally, the amount of stages and coaching that the big companies do seems ridiculous. When my girlfriend was watching an interview from Amazon telling her how she should handle the interview process I thought the whole thing just seemed so absurd.

ZSaberLink · Jan 2, 2021

Interesting discussion on the topic. I could be wrong, but a lot of the algorithms actually used in the interviews are done in college courses right? Like if you're expected to know BFS, DFS, etc.? At least that was my experience going into interviews as a college grad. It's definitely more of a pain as an industry hire though.... I agree that the process is known to weed out probably solid developers, but like others said pretty much every approach has its flaws.

At my company, we have (pre pandemic), a debugging question, a more typical "algorithm" question, a whiteboard question (for that back and forth discussion) and finally a behavioral. It's definitely not a perfect system, but it usually does weed out some candidates.

pez2k · Jan 2, 2021

Where I work, the first interview is a quick phone interview with a manager, which is just a chat to filter out anyone who can't hold a conversation, and to check they can at least make a good attempt at answering simple conceptual things like 'what is a class'. The difficulty level of those questions is usually pretty low, but if there are any specific boasts on their CV there might be a question on one of those too. It does actually clear out at least a couple of people each time the company is hiring, which saves the effort of the applicant taking time off work and the company arranging a proper interview.

The second interview is with the lead developer, which is a series of programming tasks of increasing difficulty. The tasks range from basically writing fizzbuzz up to outputting a simple Fibonnaci sequence or detecting whether a string is a palindrome. They're not intended to be anything that takes a great amount of time to write, nor requiring any specific algorithmic knowledge, and more something that can be iterated towards by thinking about the requirements and building a program bit by bit. The lead developer stays with them for the whole test, answering questions and giving hints and tips towards the solution. The applicant is then judged on how quickly they managed to understand what was required of them, how well they picked up on the hints given, and how many of the tasks they completed in a 2-3 hour window.

The goal of the second interview is to get an idea of the applicant's ability to figure out what they need to do and whether they can work towards it efficiently. It is a little algorithm-heavy, but in part that's to filter out people who are good at assembling libraries and components into a product but not so great at raw invention. The company has a legacy product in a weird language, so adaptability is more important as there are very few libraries out there that can be used, while newer products are being developed with bespoke tech in certain areas, where a new developer has the chance to contribute. The interview is very much not marked on just whether all of the tasks were completed, although managing to knock most of them out is a plus mark for an applicant just for sheer ability and speed.

I personally once interviewed for a job several years before this one, where all of the interview questions were about various quirks of a given C++ compiler, which was both excruciating and embarrassing. I think I probably would have done decently well at the job they were hiring for, but I certainly didn't have the specific knowledge they were looking for in the interview, that's for sure.

Chakoo · Jan 2, 2021

I hate technical interviews now a days for software/app development, more so than some of the crazy crap I use to do for game dev interviews.

Much of my issues with the current technical interview process is they often fail more senior devs. I've seen this time and time again with myself and close friends who have been active devs for years (15+). I've only personally found 2 types of interview processes that work really well. 1) is just having a conversation and going through the person's resume (it becomes apparent quickly when someone doesn't know half the crap they wrote down). 2) is pair programing exercise where the person doing the interview plays the roll of navigator in building out a simple common class type.

Side note, speaking of game dev interviews. I sadly can still do a dot/cross product by hand on paper because of those damn technical test even though you never ever have to do that at work. =/ The question should have more been about using a dot/cross product instead which is actually practical and many devs failed at.

Is The Modern Technical Interview Flawed For Software Engineer Candidates?

The Fallen

Charitable King

User requested account closure

User requested account closure

Charitable King

The Fallen

Senior Engineer @ Epic Games

User requested account closure