I did coding interviews for several years at Google. I hated it. A day with an interview scheduled was a bad day, relatively. I was also fairly bad at it. (Although my scores did agree with other...
I did coding interviews for several years at Google. I hated it. A day with an interview scheduled was a bad day, relatively. I was also fairly bad at it. (Although my scores did agree with other people fairly well.) Eventually I stopped. They would guilt-trip you into doing them but eventually I decided enough was enough.
I think one thing that might help is not having interviewers make up their own questions, but rather being systematic about trying different questions out and deciding which ones to keep.
Another thing that I think helps a bit is having people specialize in interviewing and try to get good at it, rather than (as was more common practice, and as I did) doing a couple a week that were a distraction from my actual work, so I'd "phone it in," reusing my same few questions I'd asked people for years. You don't want people to be interviewers for too long, but when they are, that should be their job.
I'm also unconvinced that this is something each company should do on its own. Maybe it should be centralized like the SAT's. GRE's, or the bar exam?
Alternatively, interviews could be done by the hiring team. One thing that was demotivating at Google was that there was little chance I'd ever see this person again, even if they got hired. I guess that's just a big company problem, though?
Interesting. I actually tend to like administering coding interviews (and taking them myself). I've gotten pretty good at calming peoples' nerves. It feels really good to make a nervous person...
Interesting. I actually tend to like administering coding interviews (and taking them myself). I've gotten pretty good at calming peoples' nerves. It feels really good to make a nervous person more relaxed. Granted - if someone's not just nervous but really can't do the problem I can't help them too much. The most I do in that case is cut the session short for mercy (giving them at least 30 minutes to not appear rude) and then if they're up for it I give them some advice. Sometimes it's small things like having their IDE set up right or choosing a language they're more familiar with. Yes people sometimes interview in a new language to just try it out and then do poorly.
Occasionally I offer broader career advice. I interviewed someone last week that did really bad. Like they didn't write a single line of working code and never ran anything. So I asked about what he does now. He currently just writes Perl glue code and some database queries but used to do some jQuery web dev back in the day. I described my thoughts on the vastly different environment of running Python scripts in an OS context vs. throwing a few lines of glue code together in an ETL pipeline. I said he should practice some real web dev or system programming to prepare for the job change he was trying to make. The dude was a tiny bit insecure about his capabilities - but generally seemed to really appreciate my input.
I think I just really love being a part of someone's career progression. Even if they do poorly it's nice to see people doing something to try and improve their career.
The big issue is that skillsets and specialties vary immensely, and unlike the bar exam there aren't really a core set of skills past basic 101 computing that can evaluate a candidate for a...
I'm also unconvinced that this is something each company should do on its own. Maybe it should be centralized like the SAT's. GRE's, or the bar exam?
The big issue is that skillsets and specialties vary immensely, and unlike the bar exam there aren't really a core set of skills past basic 101 computing that can evaluate a candidate for a position. Some jobs may require heavy algorithmic complexity knowledge while others will never have you do much more than using a table or list. Some consider OS/compiler knowledge as core knowledge for a computer scientists wheras I have never had to worry about anything below userland.
I imagine this gets even more complex for specialized senior positions working in networking, machine learning, AI, databases, etc.
To be honest, I think this article is pretty bad. I'll drop some critique at the end. But it triggered some decent conversations about hiring (Hacker News, lobste.rs), which I think are valuable...
To be honest, I think this article is pretty bad. I'll drop some critique at the end. But it triggered some decent conversations about hiring (Hacker News, lobste.rs), which I think are valuable and are of interest to me.
So to start with: every possible screening interview technique is going to have both false positives (i.e. you reject someone who would have been a good fit) and false negatives (i.e. you pass someone who is not a good fit). Furthermore, the false positives and false negatives are going to be biased, and biased differently per technique. (I see a lot of people criticize techniques based on their own personal aptitude; which is appropriate in a case study "this technique can fail/succeed in this way because it does so for me" sense, but useless in a population-wide "this technique's biases make it essential/useless/detrimental" sense.) The per-technique biases I see include:
No coding interview. False positives: none (unless the applicant picks up on the lack and assumes that therefore their coworkers will be incompetent). False negatives: debatable, but definitely non-zero. I've personally made hiring decisions without a coding interview of people who turned out to be nigh-incapable of writing code in a normal work environment. (One was a junior who moved halfway across the country, saving us the trouble of firing him. Another transitioned into management and then destroyed the department.) If anyone has done screening interviews and can estimate an upper bound on the false negative rate (i.e. what proportion of applicants fail a coding screen), I think that would be of interest (but also is going to vary from one job posting to another).
In-person "live coding" interview (the "whiteboard" interview). False positives: applicants who get disproportionately stressed and choke in interviews. (Per Internet anecdotes, this is common.) False negatives: traditional questions ("algorithms and data structures") are almost completely orthogonal to the actual practice of software engineering almost everywhere, and more realistic questions are difficult to make both rigorous enough to test coding skill and small enough to fit in a reasonable interview slot.
Take-home exercise. False positives: selects for applicants with plenty of free time to work on it, e.g. young and unattached, and against everyone else. False negatives: cheating is really easy. (I would expect this to reliably come out in a post-exercise debrief, but I've never actually experienced discernible cheating in a take-home exercise.)
Trial period. Actually hire the applicant for a brief probationary period and review their performance and make a permanent hiring decision at the end. False positives: you will obviously never hire anyone who's already employed with this approach. False negatives: this would strongly select for people who ingratiate themselves quickly and can jump in and start making small fixes and changes; a skill which is at least somewhat orthogonal to longer-term, larger-scale architecture and planning. Generally: no reasonable probationary period will actually be long enough for someone to come up to speed and be fully productive in a new codebase. (The rule of thumb for this is six months; my personal experience is that this is usually optimistic.) I've never heard of an employer actually doing this, so if anyone knows of one that has, I'd love to see case reports.
Of these, my personal opinion is that the take-home exercise is the least-bad option, though of course I haven't rigorously analyzed my own experiences, which are by no means universal or authoritative. You can mitigate the false positives with careful exercise design and possible explicit scoping (e.g. tell the applicant "don't spend more than a few hours on this"—though this opens the door to cheating via exceeding the time guidelines), and mitigate the false negatives with a code review and discussion.
I'd love to hear other people's opinions and impressions, though!
Okay, so, the article. A few points:
The reason I prefer asking coding questions is because I firmly believe they are the most objective way to evaluate candidates.
(Emphasis original.) This is complete baloney, of course. Interviewers will tend to ask questions they themselves can answer, putting counterpressure on diversity. And the traditional pool of questions—"algorithms and data structures"—favors applicants who had a traditional college CS education, and thus in turn are significantly whiter and more male than the general population, or probably even than the professional software developer population.
I remember feeling shocked; how is it possible that someone obviously so good can't do something so basic?
"Something so basic" is of course not designing a simple low-pass filter. It's designing a simple low-pass filter, in a high-pressure situation, under a time limit, and while being watched the whole time. I happen to be pretty good at live coding interviews, and accessory skills like narrating my thoughts while they're in process, and my performance on them (in terms of how fast/elegant is my ultimate solution) is uniformly substantially worse than if I just tackle the problem under normal circumstances.
The odds of J-random-SWE-candidate being the primary author of well-known SW are extremely low, and the vast majority of these candidates will easily solve typical coding questions.
The author presents exactly one datum to support this point, and it in fact demonstrates the exact opposite. I don't think this assertion is especially contentious, but I don't think it's universally agreeable, either, and it needs at least some defense.
It's just a hard problem, every possible solution has major issues. With regard to take-homes, I'd say that the biggest issues are the pretty high cost for grading them, possibility of cheating,...
It's just a hard problem, every possible solution has major issues. With regard to take-homes, I'd say that the biggest issues are the pretty high cost for grading them, possibility of cheating, and the fact that candidates seem to dislike them more.
About the latter, this actively selects against the kind of candidate you want (high demand, high skill candidates who know their worth will just move on, while desperate candidates will pour in hours and possibly cheat). Side note, some people seem to think that take homes are used by companies to get free labor? No, they're definitely not. The cost of having an engineer review all the submissions exceeds any possible gain by using any amount of that code by an order of magnitude.
For junior engineers, I've seen a lot of companies turn more to their intern pipelines more and more, which is effectively a trial period. For that matter, I think there's decent work being done on the gender gap from internships - but the intern pipelines actually make racial gaps worse, since companies tend to put their limited recruiting resources into a handful of prestigious universities.
Many companies effectively do trial periods for more senior positions as well in the US. The US is an at-will country, pretty much. This is the origin of the implicit or explicit stack ranking that companies like Amazon do. They lower their bar, knowing they're going to let in false positives, and therefore expect management to fire 10% or so of the workforce every year - essentially, people who fail their trial. Not a very nice environment to work in, though!
So do whiteboard interviews though. Every time I need to do whiteboarding in an interview in order to do well I need to prepare for several hours a night for at least several days in advance. I...
Take-home exercise. False positives: selects for applicants with plenty of free time to work on it, e.g. young and unattached, and against everyone else.
So do whiteboard interviews though. Every time I need to do whiteboarding in an interview in order to do well I need to prepare for several hours a night for at least several days in advance. I guess white board questions do scale better across multiple interviews, so that’s a bonus.
Personally I prefer code review style questions where the interviewer presents a set of source files (often taken and modified from actual production code) and gives you a bug report and asks you to solve the problem. You get to walk through their problem solving approach, the examples can be tailored to the level of language familiarity for the job level, and you can ask them how they would rewrite an identified problem section as well. I currently don’t do any hiring so take my opinion with a grain of salt, but I have enjoyed those interviews the most as a candidate.
I agree. My favorite question I’ve been given involved an existing demo code base with 4 bugs to fix. What kind of prep do you do? The whiteboarding questions I’ve seen are usually easy to pass if...
I agree. My favorite question I’ve been given involved an existing demo code base with 4 bugs to fix.
Every time I need to do whiteboarding in an interview in order to do well I need to prepare for several hours a night for at least several days in advance.
What kind of prep do you do? The whiteboarding questions I’ve seen are usually easy to pass if you currently work in the field and are well read.
I think there is a decent number of trivia questions that can come up, e.g. tries or Dijkstra's algorithm. There's also just the fact that I'm competing with people who are grinding weeks of...
I think there is a decent number of trivia questions that can come up, e.g. tries or Dijkstra's algorithm. There's also just the fact that I'm competing with people who are grinding weeks of leetcode or whatever questions before an interview and the last time I would have done any graph or DP related questions would have been in an interview or prepping for one 3+ years ago, thus I feel the need to be familiar with it.
Having lived on this earth and experience stage fright myself I’m sure there’s truth to this. But this is surely also capturing many people that are deluding themselves into thinking anxiety was...
applicants who get disproportionately stressed and choke in interviews. (Per Internet anecdotes, this is common.)
Having lived on this earth and experience stage fright myself I’m sure there’s truth to this. But this is surely also capturing many people that are deluding themselves into thinking anxiety was the only thing holding them back.
I interview a lot of software engineers. Many of them just straight up can not code. They’re usually currently unemployed, and have experience in larger companies where I assume you can get away with being unproductive for long periods of time.
Then there’s a big chunk of people that can code but can’t finish in the time window. These people could do just fine if they actually write code for 6+ hours per day. That locks them into Junior-level roles but hey - those still pay well. Sadly I need to pass on them because all I see is the tech screen performance and can’t extrapolate too far. But sometimes they get really close and they get a thumbs up because no one needs to be perfect.
Then there are people that break down the problem in 5 minutes and write the 30-or-so lines needed in 25 minutes. Nothing fancy is needed. Just hash maps and for loops. These people give me the impression that they’ve just written tons of code before. They haven’t memorized problems - they just have mastered the basics and truly deeply grok them. They’re probably hobbyists and would be programmers even if the pay wasn’t great. Ideally these are most of the people I hire for SWE roles.
I know there probably isn't a catch all for this type of person, but have you found groups that tend to have higher densities of this type of person? Our little company is growing so I'm...
Then there are people that break down the problem in 5 minutes and write the 30-or-so lines needed in 25 minutes. Nothing fancy is needed. Just hash maps and for loops. These people give me the impression that they’ve just written tons of code before. They haven’t memorized problems - they just have mastered the basics and truly deeply grok them. They’re probably hobbyists and would be programmers even if the pay wasn’t great. Ideally these are most of the people I hire for SWE roles.
I know there probably isn't a catch all for this type of person, but have you found groups that tend to have higher densities of this type of person? Our little company is growing so I'm consistently hiring and sifting through the mountains of resumes is exhausting. We've had the most success with early career folks who reach out to us through academic partners or experience engineers connected from within our network. Actual 'job post' hiring has been a debacle.
Agreed those are the best sources. You want to hire people that are moving up in their career - and that isn't always possible when hiring experienced people unless your company is a unicorn. So...
We've had the most success with early career folks who reach out to us through academic partners or experience engineers connected from within our network.
Agreed those are the best sources. You want to hire people that are moving up in their career - and that isn't always possible when hiring experienced people unless your company is a unicorn. So getting smart new grads is a great option. And your network of excellent ex-colleagues is already a selection of the best among many people. You just need to catch them during a transition.
I think there must be some good heuristics for determining if a GitHub profile is high quality or not. Armed with those you could go through hundreds or thousands of candidates and then either reach out to the ones you think are likely to interview or keep tabs on the ones that are happily employed and wait for that to change. Recruiters either throw too wide of a net (your LinkedIn page says "Ruby on Rails"? Here's a Rails opportunity for you) or have too many people that need help looking for a job.
I don't currently handle the top-of-funnel resume trawling but if I did I'd look for people that participated heavily in something like Advent of Code where I can see their work. That limits your search exclusively to people that love programming and also gives you a nice opportunity for previewing how they code even when they think no one's watching. So maybe go here, add some extra filters, and see who's looking for work. You can either get emails from their profile or extract them from their commits.
If this ever becomes a popular hiring method it will become useless. But for now I don't think many people are doing it.
:D I feel a bit guilty telling you to more-or-less cold email people. You'll need to know how to grab someone's attention once you find a good candidate. You can differentiate yourself from big...
:D
I feel a bit guilty telling you to more-or-less cold email people. You'll need to know how to grab someone's attention once you find a good candidate. You can differentiate yourself from big recruiting firms by actually stating compensation numbers and benefits in the title. And the less your email looks like it's meant for a massive email blast the better you'll fair. I'd recommend you start off with a bit of flattery on what you liked about their Github profile. If I thought that a recruiting email was both hand-typed and the person gave enough of a damn to see my GitHub projects I'd be very interested in at least reading the whole email.
That is great advice. I've actually been putting together a document on prospective employees that gets updated every time I come across an ideal candidate be it through linkedin, publications,...
That is great advice. I've actually been putting together a document on prospective employees that gets updated every time I come across an ideal candidate be it through linkedin, publications, competitors, or partners. I think I'll try this approach with them.
I recently received an email like this and even though the timing does not work out, that email got saved for when the timing might be better. I will certainly remember that company and give them...
I recently received an email like this and even though the timing does not work out, that email got saved for when the timing might be better. I will certainly remember that company and give them strong consideration in the future.
I've been interviewing lately and although I don't think coding interviews are the perfect way to go (and I certainly dreaded them before starting), they're also comforting at times in a sense of...
I've been interviewing lately and although I don't think coding interviews are the perfect way to go (and I certainly dreaded them before starting), they're also comforting at times in a sense of consistency. The more interviews you do at places that do coding interviews, the more it helps you build up confidence and ability for later interviews. You can progress through leetcode (or what not) practicing the fundamentals of algorithms and data structures, and read through a book about system design -- now you're good to go for 90% of interviews.
I did a final round at Amazon (for a software eng role) and the part I didn't like was actually the values chat (i.e. the part where you talk about your work style and projects you've done), the coding interviews were pretty straightforward and what I had gotten used to with other interviews (and with preparation). The segments I didn't do well in, I could at least tell I wasn't doing well in, and could earmark that for later to improve on for future interviews.
The values chat at Amazon were what I think a lot of people are pining for as a better alternative for interviews, a way of just having a conversation with your potential future peers about work you've done, and you can wow them with what you've done, without even knowing how to reverse a linked list.
That's not what those value chats were though, they were asking questions they were reading off of a form, you give an answer, they give vaguely related followup questions that are clearly driving towards a text box on their screen they have to fill in with what you say, and a major part of your interview success is now how well your answers are aligning with what they need to write down. If they ask you a time you've been proactive about learning something, would you be able to come up with a good example on the spot? Is it an impressive example? What if your current position was pretty straightforward and you haven't needed to learn new things for it. What if the example you chose doesn't lead itself well to followups, is that entire question a write-off for you now because you chose the wrong example on the spot? What if you've concentrated on helping your team run smoothly, filling out a leadership role, but not actively learning something new, so you don't have a good example to give? Did that just hurt your chances at this interview? And unlike the coding portion, you don't get good feedback about this part -- how do you know whether you just bombed a values question? With an algorithm or system design you can tell if it worked, or if you were running close to out of time, or if it was very inefficient.
I had a different interview the other day with a smaller startup, and it was 2.25 hours of just talking, talking about projects I've done, talking about times in the past where I've bipped and bopped and dizzled and dozzled or whatever. After an hour of that you start getting really tired of just talking about random things you've done, and half-remember from months or years ago -- if you have examples that line up nicely with the question at all.
And then the dangerous questions: what if someone goes through this process who isn't a strong communicator, or is reserved and doesn't give a lot of details what would help them, or are tired of talking for an hour and start giving sloppy answers -- what if they have a strong accent and the interviewers don't understand them? Did you just filter out people who could be good at their jobs (especially over text-based communication like most places do now) because of an accent? Would your hiring team even know that that's the reason?
After a few of those interviews at different places, you start running on half-autopilot when you're answering these questions, losing the excitement in your voice, potentially skipping details, and wondering if you've been failing a few of these from using a bad example, or not having impressive enough examples. Did switching away from coding interviews help your companies chances at finding good talent and filtering out talent-that-doesn't-align-with-what-you're-hiring-for? Maybe it hurt it and you don't even realize.
Anyway just as a disclaimer, the way I've seen in a few places that's really the best way of going about it IMO is:
an initial 45 minute to 1 hour screener with a simple technical question, just something to make sure you're not a fraud before going to the next or final round
1 hour of coding an algorithm or similar-to-real-work kind of example, can be harder, but something to see how you work around a problem and approach it
1 hour of system design (this is for back-end and fullstack interviews, so specific to those) to see how you think about constraints in the real world, and building an architecture that's reasonable and scalable
1 hour of talking, hopefully with someone you will be actually working closely with if you get hired
I did coding interviews for several years at Google. I hated it. A day with an interview scheduled was a bad day, relatively. I was also fairly bad at it. (Although my scores did agree with other people fairly well.) Eventually I stopped. They would guilt-trip you into doing them but eventually I decided enough was enough.
I think one thing that might help is not having interviewers make up their own questions, but rather being systematic about trying different questions out and deciding which ones to keep.
Another thing that I think helps a bit is having people specialize in interviewing and try to get good at it, rather than (as was more common practice, and as I did) doing a couple a week that were a distraction from my actual work, so I'd "phone it in," reusing my same few questions I'd asked people for years. You don't want people to be interviewers for too long, but when they are, that should be their job.
I'm also unconvinced that this is something each company should do on its own. Maybe it should be centralized like the SAT's. GRE's, or the bar exam?
Alternatively, interviews could be done by the hiring team. One thing that was demotivating at Google was that there was little chance I'd ever see this person again, even if they got hired. I guess that's just a big company problem, though?
Interesting. I actually tend to like administering coding interviews (and taking them myself). I've gotten pretty good at calming peoples' nerves. It feels really good to make a nervous person more relaxed. Granted - if someone's not just nervous but really can't do the problem I can't help them too much. The most I do in that case is cut the session short for mercy (giving them at least 30 minutes to not appear rude) and then if they're up for it I give them some advice. Sometimes it's small things like having their IDE set up right or choosing a language they're more familiar with. Yes people sometimes interview in a new language to just try it out and then do poorly.
Occasionally I offer broader career advice. I interviewed someone last week that did really bad. Like they didn't write a single line of working code and never ran anything. So I asked about what he does now. He currently just writes Perl glue code and some database queries but used to do some jQuery web dev back in the day. I described my thoughts on the vastly different environment of running Python scripts in an OS context vs. throwing a few lines of glue code together in an ETL pipeline. I said he should practice some real web dev or system programming to prepare for the job change he was trying to make. The dude was a tiny bit insecure about his capabilities - but generally seemed to really appreciate my input.
I think I just really love being a part of someone's career progression. Even if they do poorly it's nice to see people doing something to try and improve their career.
The big issue is that skillsets and specialties vary immensely, and unlike the bar exam there aren't really a core set of skills past basic 101 computing that can evaluate a candidate for a position. Some jobs may require heavy algorithmic complexity knowledge while others will never have you do much more than using a table or list. Some consider OS/compiler knowledge as core knowledge for a computer scientists wheras I have never had to worry about anything below userland.
I imagine this gets even more complex for specialized senior positions working in networking, machine learning, AI, databases, etc.
To be honest, I think this article is pretty bad. I'll drop some critique at the end. But it triggered some decent conversations about hiring (Hacker News, lobste.rs), which I think are valuable and are of interest to me.
So to start with: every possible screening interview technique is going to have both false positives (i.e. you reject someone who would have been a good fit) and false negatives (i.e. you pass someone who is not a good fit). Furthermore, the false positives and false negatives are going to be biased, and biased differently per technique. (I see a lot of people criticize techniques based on their own personal aptitude; which is appropriate in a case study "this technique can fail/succeed in this way because it does so for me" sense, but useless in a population-wide "this technique's biases make it essential/useless/detrimental" sense.) The per-technique biases I see include:
Of these, my personal opinion is that the take-home exercise is the least-bad option, though of course I haven't rigorously analyzed my own experiences, which are by no means universal or authoritative. You can mitigate the false positives with careful exercise design and possible explicit scoping (e.g. tell the applicant "don't spend more than a few hours on this"—though this opens the door to cheating via exceeding the time guidelines), and mitigate the false negatives with a code review and discussion.
I'd love to hear other people's opinions and impressions, though!
Okay, so, the article. A few points:
(Emphasis original.) This is complete baloney, of course. Interviewers will tend to ask questions they themselves can answer, putting counterpressure on diversity. And the traditional pool of questions—"algorithms and data structures"—favors applicants who had a traditional college CS education, and thus in turn are significantly whiter and more male than the general population, or probably even than the professional software developer population.
"Something so basic" is of course not designing a simple low-pass filter. It's designing a simple low-pass filter, in a high-pressure situation, under a time limit, and while being watched the whole time. I happen to be pretty good at live coding interviews, and accessory skills like narrating my thoughts while they're in process, and my performance on them (in terms of how fast/elegant is my ultimate solution) is uniformly substantially worse than if I just tackle the problem under normal circumstances.
The author presents exactly one datum to support this point, and it in fact demonstrates the exact opposite. I don't think this assertion is especially contentious, but I don't think it's universally agreeable, either, and it needs at least some defense.
It's just a hard problem, every possible solution has major issues. With regard to take-homes, I'd say that the biggest issues are the pretty high cost for grading them, possibility of cheating, and the fact that candidates seem to dislike them more.
About the latter, this actively selects against the kind of candidate you want (high demand, high skill candidates who know their worth will just move on, while desperate candidates will pour in hours and possibly cheat). Side note, some people seem to think that take homes are used by companies to get free labor? No, they're definitely not. The cost of having an engineer review all the submissions exceeds any possible gain by using any amount of that code by an order of magnitude.
For junior engineers, I've seen a lot of companies turn more to their intern pipelines more and more, which is effectively a trial period. For that matter, I think there's decent work being done on the gender gap from internships - but the intern pipelines actually make racial gaps worse, since companies tend to put their limited recruiting resources into a handful of prestigious universities.
Many companies effectively do trial periods for more senior positions as well in the US. The US is an at-will country, pretty much. This is the origin of the implicit or explicit stack ranking that companies like Amazon do. They lower their bar, knowing they're going to let in false positives, and therefore expect management to fire 10% or so of the workforce every year - essentially, people who fail their trial. Not a very nice environment to work in, though!
So do whiteboard interviews though. Every time I need to do whiteboarding in an interview in order to do well I need to prepare for several hours a night for at least several days in advance. I guess white board questions do scale better across multiple interviews, so that’s a bonus.
Personally I prefer code review style questions where the interviewer presents a set of source files (often taken and modified from actual production code) and gives you a bug report and asks you to solve the problem. You get to walk through their problem solving approach, the examples can be tailored to the level of language familiarity for the job level, and you can ask them how they would rewrite an identified problem section as well. I currently don’t do any hiring so take my opinion with a grain of salt, but I have enjoyed those interviews the most as a candidate.
I agree. My favorite question I’ve been given involved an existing demo code base with 4 bugs to fix.
What kind of prep do you do? The whiteboarding questions I’ve seen are usually easy to pass if you currently work in the field and are well read.
I think there is a decent number of trivia questions that can come up, e.g. tries or Dijkstra's algorithm. There's also just the fact that I'm competing with people who are grinding weeks of leetcode or whatever questions before an interview and the last time I would have done any graph or DP related questions would have been in an interview or prepping for one 3+ years ago, thus I feel the need to be familiar with it.
Having lived on this earth and experience stage fright myself I’m sure there’s truth to this. But this is surely also capturing many people that are deluding themselves into thinking anxiety was the only thing holding them back.
I interview a lot of software engineers. Many of them just straight up can not code. They’re usually currently unemployed, and have experience in larger companies where I assume you can get away with being unproductive for long periods of time.
Then there’s a big chunk of people that can code but can’t finish in the time window. These people could do just fine if they actually write code for 6+ hours per day. That locks them into Junior-level roles but hey - those still pay well. Sadly I need to pass on them because all I see is the tech screen performance and can’t extrapolate too far. But sometimes they get really close and they get a thumbs up because no one needs to be perfect.
Then there are people that break down the problem in 5 minutes and write the 30-or-so lines needed in 25 minutes. Nothing fancy is needed. Just hash maps and for loops. These people give me the impression that they’ve just written tons of code before. They haven’t memorized problems - they just have mastered the basics and truly deeply grok them. They’re probably hobbyists and would be programmers even if the pay wasn’t great. Ideally these are most of the people I hire for SWE roles.
I know there probably isn't a catch all for this type of person, but have you found groups that tend to have higher densities of this type of person? Our little company is growing so I'm consistently hiring and sifting through the mountains of resumes is exhausting. We've had the most success with early career folks who reach out to us through academic partners or experience engineers connected from within our network. Actual 'job post' hiring has been a debacle.
Agreed those are the best sources. You want to hire people that are moving up in their career - and that isn't always possible when hiring experienced people unless your company is a unicorn. So getting smart new grads is a great option. And your network of excellent ex-colleagues is already a selection of the best among many people. You just need to catch them during a transition.
I think there must be some good heuristics for determining if a GitHub profile is high quality or not. Armed with those you could go through hundreds or thousands of candidates and then either reach out to the ones you think are likely to interview or keep tabs on the ones that are happily employed and wait for that to change. Recruiters either throw too wide of a net (your LinkedIn page says "Ruby on Rails"? Here's a Rails opportunity for you) or have too many people that need help looking for a job.
I don't currently handle the top-of-funnel resume trawling but if I did I'd look for people that participated heavily in something like Advent of Code where I can see their work. That limits your search exclusively to people that love programming and also gives you a nice opportunity for previewing how they code even when they think no one's watching. So maybe go here, add some extra filters, and see who's looking for work. You can either get emails from their profile or extract them from their commits.
If this ever becomes a popular hiring method it will become useless. But for now I don't think many people are doing it.
This is such good advice. Thank you so much for the suggestion!
:D
I feel a bit guilty telling you to more-or-less cold email people. You'll need to know how to grab someone's attention once you find a good candidate. You can differentiate yourself from big recruiting firms by actually stating compensation numbers and benefits in the title. And the less your email looks like it's meant for a massive email blast the better you'll fair. I'd recommend you start off with a bit of flattery on what you liked about their Github profile. If I thought that a recruiting email was both hand-typed and the person gave enough of a damn to see my GitHub projects I'd be very interested in at least reading the whole email.
That is great advice. I've actually been putting together a document on prospective employees that gets updated every time I come across an ideal candidate be it through linkedin, publications, competitors, or partners. I think I'll try this approach with them.
I recently received an email like this and even though the timing does not work out, that email got saved for when the timing might be better. I will certainly remember that company and give them strong consideration in the future.
I've been interviewing lately and although I don't think coding interviews are the perfect way to go (and I certainly dreaded them before starting), they're also comforting at times in a sense of consistency. The more interviews you do at places that do coding interviews, the more it helps you build up confidence and ability for later interviews. You can progress through leetcode (or what not) practicing the fundamentals of algorithms and data structures, and read through a book about system design -- now you're good to go for 90% of interviews.
I did a final round at Amazon (for a software eng role) and the part I didn't like was actually the values chat (i.e. the part where you talk about your work style and projects you've done), the coding interviews were pretty straightforward and what I had gotten used to with other interviews (and with preparation). The segments I didn't do well in, I could at least tell I wasn't doing well in, and could earmark that for later to improve on for future interviews.
The values chat at Amazon were what I think a lot of people are pining for as a better alternative for interviews, a way of just having a conversation with your potential future peers about work you've done, and you can wow them with what you've done, without even knowing how to reverse a linked list.
That's not what those value chats were though, they were asking questions they were reading off of a form, you give an answer, they give vaguely related followup questions that are clearly driving towards a text box on their screen they have to fill in with what you say, and a major part of your interview success is now how well your answers are aligning with what they need to write down. If they ask you a time you've been proactive about learning something, would you be able to come up with a good example on the spot? Is it an impressive example? What if your current position was pretty straightforward and you haven't needed to learn new things for it. What if the example you chose doesn't lead itself well to followups, is that entire question a write-off for you now because you chose the wrong example on the spot? What if you've concentrated on helping your team run smoothly, filling out a leadership role, but not actively learning something new, so you don't have a good example to give? Did that just hurt your chances at this interview? And unlike the coding portion, you don't get good feedback about this part -- how do you know whether you just bombed a values question? With an algorithm or system design you can tell if it worked, or if you were running close to out of time, or if it was very inefficient.
I had a different interview the other day with a smaller startup, and it was 2.25 hours of just talking, talking about projects I've done, talking about times in the past where I've bipped and bopped and dizzled and dozzled or whatever. After an hour of that you start getting really tired of just talking about random things you've done, and half-remember from months or years ago -- if you have examples that line up nicely with the question at all.
And then the dangerous questions: what if someone goes through this process who isn't a strong communicator, or is reserved and doesn't give a lot of details what would help them, or are tired of talking for an hour and start giving sloppy answers -- what if they have a strong accent and the interviewers don't understand them? Did you just filter out people who could be good at their jobs (especially over text-based communication like most places do now) because of an accent? Would your hiring team even know that that's the reason?
After a few of those interviews at different places, you start running on half-autopilot when you're answering these questions, losing the excitement in your voice, potentially skipping details, and wondering if you've been failing a few of these from using a bad example, or not having impressive enough examples. Did switching away from coding interviews help your companies chances at finding good talent and filtering out talent-that-doesn't-align-with-what-you're-hiring-for? Maybe it hurt it and you don't even realize.
Anyway just as a disclaimer, the way I've seen in a few places that's really the best way of going about it IMO is: