I generally don't mind whiteboard programming interviews but even so asking someone to implement merge sort is a bad question.
My sanity check for any question I ask is- Is the question I'm asking something that someone in the past published a paper about? If so then that's probably not a good fit for a 45 minute whiteboarding interview. This question falls in that category. Generally those algorithms are complex enough that it is unrealistic to expect someone to get them right from first principles so at that point you are just selecting for people who just happened to have dealt with them, memorized them or implemented them recently.
I have a co-worker who used to ask people to past to parse and evaluate infix notation expressions in interviews (and there are companies that ask that question). Always stuck me as weird as multiple papers have been written about that problem, are you really expecting someone to implement a solution to a problem that people spend weeks (months?) thinking about before publishing? Could even Djikstra have come up with the Shunting Yard Algorithm in a 45 minute interview (with implementation on whiteboard) if that was his first exposure to the problem of expression parsing?
My impression of the facebook interview experience was that it is specifically selecting people that were calm under pressure and well rehearsed. They are testing for people that put in the effort to crank out a bunch of algorithms practice because they want to ace an interview. FB and Amazon were also explicit that they were looking for people with a particular "get things done and promote myself" attitude. Whether or not those people make good employees, I don't know.
When I interviewed at FB, every round was something that I had drilled on leetcode or similar sites. Yes, the wording was changed and the problems were altered a bit, but they were the same algorithms. And there were also two "lightning" rounds of 15 minutes each to solve two simpler algorithms problems (maybe easy/medium difficulty on leetcode). This experience gave me the impression that facebook's goals in hiring were to select people who really wanted the job and could pass quizzes well.
Yep. I think it goes further than whether there's a published paper about. It boils down to "does the question have exactly one correct answer?"
One important thing you learn in interviewer workshops is to avoid asking questions with "aha" components, i.e. things that can only be solved if a very specific insight is known. This type of question is problematic because it falls victim to the fallacious assumption that a candidate that excels in one specific problem must necessarily excel at others that are in actuality, at best, only marginally related.
Instead, it is better to ask questions for which the solution can be arrived at with small increments in effort (e.g. maybe there's an obvious brute force solution and you start from there to discuss more optimal solutions, or maybe the candidate got stuck on some specific peculiarity and you can give a hint to unblock them and move on to another part of the problem to get more signal)
I don't think whiteboard programming is really a good metric for measuring someone's skills for a normal software engineering job.
However, assuming that extensive knowledge of certain algorithms (like merge sort), data structures, or computational methods are necessary for a particular job, I think a better question to ask isn't "how do you implement merge sort" but instead to present the merge sort algorithm and then ask the interviewee how it works based on the code given. Obviously still not the best way to assess someone's skills, but I think it's better than just memorizing a bunch of algorithms without being able to explain how they work.
> Always stuck me as weird as multiple papers have been written about that problem, are you really expecting someone to implement a solution to a problem that people spend weeks (months?) thinking about before publishing
except that these things aren't research material anymore and are now taught at undergraduate level.
> My sanity check for any question I ask is- Is the question I'm asking something that someone in the past published a paper about? If so then that's probably not a good fit for a 45 minute whiteboarding interview.
Also, is it a widely known algorithm? Because then I'm not measuring for programming ability; I'm measuring for rote memorization (there are people that will rote memorize all the sorting algos to be able to spit them out during interviews!).
Asking for a simply program like wc, in my opinion, gives a much better idea if someone can code (hint: there's not a single way of writing it and to define a word).
> I have a co-worker who used to ask people to past to parse and evaluate infix notation expressions in interviews
That's a cool problem to use. I wouldn't expect a perfect parser or even a working one but I would be curious to see how they approach the problem and what they end up writing.
Say that it's a binary merge sort over a singly linked list.
A binary merge sort, if written recursively, is straightforward divide-and-conquer. The input list is divided into two halves, which are separately sorted via recursion, and then the sorted halves are merged to produce the sorted output.
The algorithm pops out of the definition. If you know the above definition (or the interviewer has provided it, which they should!) the rest is just an exercise which demonstrates that you can:
- completely analyze a problem's cases, including figuring out the existence of cases that are not spelled out in the description (like how to terminate the recursion)
- manipulate pointers
- decompose a problem into small, simple functions that you can separately reason about: (merging two lists, chopping a list in half, and such).
It's not such a bad interview question. I would actually tell all the candidates at least a day ahead of time that they will be implementing merge sort in C using a singly linked list during the interview, so they can study it all they want and rehearse coding it.
It's complicated enough that it can't just be regurgitated from memory by someone who doesn't know what the are doing. (Say, someone who had someone else write the code, and then tried to rote memorize it.) The memory has to be accompanied by understanding if the candidate is to reconstruct it with few or no flaws.
Wirth's "Pascal User Manual and Report" has a listing of a program on pg 75 that does just that. Except it emits the expressions in postfix form rather than evaluating them. It's 31 lines of code, including declarations and `end` statements.
K+R "The C Programming Language" has a desk calculator that evaluates postfix form on pages 74-75 which is about 60 lines of code including lines with just a {, and handles +-*/= including user interface and error checking.
I was just watching a Jon Gjengset "Crust of Rust" stream on sorting, and when his quicksort implementation kept going sideways, I was like "haha how nostalgic".
> I was interviewing at various places, and I got an interview with the Apple Watch team
Funnily enough, I also interviewed with the Apple Watch team around the same time and had a similar negative experience.
I was struggling with a problem on the whiteboard and paused to ask a question. Instead, one of the interviewers (it was a pair) turned to the other and said “I wish the Calendar complication on my watch would show when this meeting ends”
All the other interviewers that day were great, but it just takes a few bad apples… Even though it’s been years and I’ve had a nice tenure at FAANG, I’ll never consider joining Apple after that experience.
A candidate asking questions and trying to unblock himself is an extremely positive signal. It means they are capable of communicating and not start panicking when they hit a blocker.
Ouch! I once interviewed at a local company that used the same hardware and OS as my then employer. When I told the guy where I worked he started laughing. He apologized but he was sympathetic in a you poor bastard kind of way.
I’ve had so many poor interview experiences and all of them at the big tech companies. I once went to google and only 2/5 interviewers bothered to show up.
Hell, in an interview I had this week I was given multiple incorrect answers to my clarification questions. Even when I said “I believe I answered it” the interviewer said “I don’t think so” until he finally looked up and was like “oh you got it”
I’m on zoom watching the interviewer text / look at other screens as I ask clarifying questions and they give dismissive answers “yea yea that sounds right, do that” while never looking up from their phone. Was a pretty “wtf” moment. I completed the interview, but I got the feeling the review will be subpar.
> Trick questions and esoteric puzzles give the interviewer no useful information about the interviewee — her skills, her strengths, her weaknesses, her potential for growth. Those are the things a great interviewer should be seeking out. That means you give hints when the candidate gets stuck and you don’t interrupt them with asinine comments. Whatever problem you give a candidate to solve, your goal as an interviewer should be to get them through as much of that problem as possible, to get as much signal as possible. The added benefit is that the further you get, the better and more confident the candidate feels, which also helps prepare them to do their best for the next session. Less experienced interviewees often need more help, and that’s ok.
This article lays out the problem very well, but then again so to very many others which have appeared on HN over the years.
Why does this keep happening? I mean this at the most fundamental level.
Why waste time with programming puzzlers to begin with? Does the candidate's degree (assuming no job experience) not obviate the need for this kind of thing? Do past programming gigs not absolve them of the need to perform in a way they'll never be asked to perform on the job? Are CS departments so full of bullshitters that unless you sic your 10x devs on them to sniff out whether they can program their way out of a paper bag, your organization runs the risk of filling up with "C Players?"
I ask tech questions in interviews as a litmus test (for any given concept) and it always relates directly to the work being done so they can get a feel of the kind of code they would be writing and maintaining.
As an example -- in my line of work, one task we perform is processing files, some small, some medium, some very large; and I wanted to make sure a candidate understood the concept of Maps in order to perform O(n) to create a map and O(1) to look up items (generally speaking, I'm sure it's not exactly that in practice), which aide in efficient processing (the age old processor vs memory tradeoff). This particular candidate got everything I asked immediately, and the interview was very short. The person was made an offer soon after and has gone on to learn what we've done, adapt, and also teach us some things that have made the software better.
And the moment candidates grok the concepts I'm after, I confirm that's what I was after, and move on, trying not to waste too much time on any given item. And if they don't get the concepts after a short while, I try to lead them there and see how they react (is it a lightbulb moment or a confusion moment, etc). These are all signs for me to determine if someone is right for the position.
Interviewing is a 2-way street of respect. The interviewer often has all the perceived power, but in my experience, a good interviewer eschews that perception right from the get-go and lets the interviewee know that this is more of a discussion than any kind of trickery or exam, even when it contains coding questions.
This is why I will never interview for Google or any other company that has multi-stage interviews and also employs time-wasteful, and sometimes esoteric, methods such as "How many jelly beans fit in a school bus?"
My worst tech interview was with me as the interviewer. An applicant was a friend of a coworker and forwarded the candidate's resume to HR. HR set up a round of interviews.
He went through the five interviews. After, we met for 20 minutes to express our thoughts. Pretty uniformly we agreed: the candidate was middling and we'd be better off waiting for someone better. We rejected him.
A day later the rejected candidate called my phone (how did he get it?) and said something like: "Hey, this is <candidate>. Why the hell wasn't I given an offer? The recruiter said that you (that is me, personally) had rejected me. Explain why." He insisted he had done great and we should reconsider.
The candidate hadn't reacted well to the rejection, and rather than being the firewall that shields the interviewers, the HR guy passed the buck and blamed me. We didn't reconsider, and I gave the HR guy hell about it.
Author states that the following threw him off: Interviewer: "you must be writing a lot of Swift" after a few minor syntax errors.
Maybe being put off by an ambiguous comment was why you didn't get the job? Did you consider maybe in his notes he might've said: "Smart guy but was put off by a single comment (a failed attempt at humour on my part). Probably not someone who would thrive in a lively atmosphere".
I had an interviewer ask a question and, not satisfied with the answer, get up and walk out. The other guy apologized and we had a good discussion after the other guy left.
> "Smart guy but was put off by a single comment (a failed attempt at humour on my part). Probably not someone who would thrive in a lively atmosphere"
This sounds like a cartoonish training example of the kind of subjective, possibly biased feedback that you absolutely shouldn’t be writing down as an interviewer.
If you’re making jokes like this in an interview, you shouldn’t be an interviewer. There is a clear power imbalance between interviewer and interviewee that needs to be understood clearly.
A somewhat comparable analogy is your manager joking about firing you and then evaluating you negatively when you don’t like the joke.
There is absolutely 0 signal there as to whether someone would "thrive in a lively atmosphere" when you're jumping through hoops for an interview that will determine your financial well being and a good portion of your live for the next n years, and its a fun example of how "engineer social hacks" continuously fail in the real world.
Ah, so you're saying you're financially and emotionally secure enough not to be completely discombobulated by this incredible display of disrespect?
Good for you I guess, but maybe don't apply your own mental blueprint to the rest of the world. Recommending candidates have thicker skin isn't really great a way to improve hiring in general.
I've had a ton of bad interview experiences, but my worst was still Google. This was circa 2012 or so, was my 2nd session of an on-site day. I guess I didn't grow up around a lot of people with thick accents because I could literally not understand a single word this guy was saying, and he didn't seem to understand me. He wanted me to explain the solution before writing any code, but since we were having communication issues I asked if I could write pseudocode.
He slammed (SLAMMED) his fist onto the table and yelled, "NO CODE!"
-----
Other bad experiences included Palantir telling me my onsite went really well, and that they'd like me to come in again to meet the hiring manager. Expecting to talk business, I instead was presented with 2 more algorithm questions. Those apparently went OK, so the next discussion with the recruiter yielded another "informal" (his words) meeting with 2 engineers via VC. Both ended up being 2 more DS/Algo questions.
-----
Another bad one I remember is a request to do a take-home coding test from Docusign (also circa 2012). They wanted me to program a "fully tested" elevator simulation using Stylus, Coffeescript, and Jade. I had never used any of these technologies, so I asked if I could write it in what I was familiar with (jQuery, Backbone, SCSS, ES5), which was denied. It would have taken me a full week to get up to speed on all of those technologies enough to submit a solution worthy of review. Absolutely ridiculous to ask a candidate to learn new frameworks just to complete the interview.
Had an interview yesterday where the guy was seemingly more nervous than I was, and he seemed to mask that nervousness with anger/being rude. I would answer his questions, and he would act like I wasn't understanding the question. In reality, it turns out I wasn't answering his questions using the _exact_ buzzwords he was looking for. I realized this when I happened to mention a buzzword after minutes of tense back-and-forth and he immediately perked up and we could suddenly move on. Went into the next interview feeling like shit because of this.
This whole process is so broken. Great devs get passed up on for terrible devs who know how to grind Leetcode and the like. I hate having to grind leetcode for weeks just to end up getting asked obscure algorithm puzzle questions that I could never prepare for. And all for a 100% React job? Jesus.
Same problem with a poor English speaker at Google back in ~2019. It took several minutes just to start understanding the words he was saying. I have many years of working/growing up with ESL folks and have a good ear for it and still struggled with this guy.
At one of the FAANGs the number one thing they drummed in during training for the interviewer is that "interviews are not an opportunity to make you, the interviewer, appear smart!".
It's obvious but geek culture sometimes need things like this explicitly stated.
What's so interesting about this experience it hits so many of the points I've been complaining about in my writing about hiring in the tech industry[0]:
- Giving trick questions that have an "insight" moment, instead of one that has multiple answers, even partial answers to build off of.
- Not letting the candidate pick the language they're comfortable with. The candidate may even know the language they're asked to code in, but if they haven't been working with it recently, an interview is not the right time to pick it up again.
- Making the candidate nervous, both by not being helpful and by watching over them with unnecessary scrutiny.
- Looking for flaws instead of strengths.
People, myself included, are always talking about these problems, but companies have so much inertia, they are not evolving fast enough to solve these problems. No wonder tech companies are filled with people who, while capable, often fit a particular mold, and why we end up in situations where products don't reflect the needs of the market (because the people working on those products aren't representative of the market).
i was slightly sleep deprived for an algo interview and the interviewer just pasted problems into coderpad and just said nothing, i might have solved it if the guy was friendly but the absolute silence made me hear time ticking in my sleep deprived state and i psyched myself out. I went home and answered both the questions pretty handily, but man the interviewer demeanor plays such a big role in interviews.
1. Being steered away from my answer for an algorithm problem, towards the interviewers preferred answer. When I reflected back on it later, I realised that my answer would have been more efficient for the specific problem asked, whilst the interviewers solution was for a more general version of the problem (which wasn't ever asked).
2. Being given feedback that I was weak on data structures, when there hadn't been any questions about data structures. I am weak on data structures though, so perhaps they just peered into my brain somehow.
3. Being told I wasn't suitable for remote positions because I was too verbose answering questions which were essentially trivia -- when I was intentionally trying to capture nuance because I didn't want to fall prey to trick questions.
1 and 2 were for the same company, but different stages.
It seems like companies do not understand that they are competing for programmers as much as programmers are competing for companies. If you're a programmer with at least one big N job under your belt, you don't have to take bad treatment. You don't have to deal with terrible interviews or really long processes. The power is on your side. It's only because most programmers don't understand the balance of power that companies keep getting away with this nonsense. I marvel at how companies are throwing away their chances at top talent due to these horrible processes.
I recently applied and got an offer from a big N company. It took forever, easily three times the length of my other processes. I was not given any insight into my team beyond an overarching organization. The pay was not fantastic and they didn't honor my first location request. Why would I accept this? The pay I could have negotiated. But I'd still be put into a random, likely boring team in a city I didn't pick as my first choice. All to be able to work at a "Big N" company, when I've already had that experience. Maybe that works on some people but after the first Big N it's really not important.
I've had bad interview experiences. I think most of us who've been working for awhile have. I have advice for those who are newish: Walk away if you're uncomfortable. If you're not feeling right in the interview I bet you won't feel right on the job, either. If you're being mistreated just walk away.
Bonus points for getting up while the interviewer is in mid-sentence and telling them it's not a fit.
I was with you until the last sentence. The best way to respond to rudeness is clearly and politely, unless they're screaming, berating, or threatening you. If you make a habit of responding to rudeness by acting politely, you will impress everyone other than the perpetrator(s).
My company does white board interviews and I always make a point of telling the interviewee that I'm not looking for syntax and just want to see the overall algorithm and program flow. If he wants to make a library call and can't remember the args, I tell him to make it up - I don't care if he can remember a trivial fact that his IDE will tell him or that he'll find in a quick manual page lookup.
(while I meant "he" as a gender-neutral pronoun, sadly, nearly all of our senior tech candidates are male, but one bright spot is that we've got near gender parity with college interns which I hope means the job market is becoming more balanced)
A big Fintech company asked me to go to wikipedia and look up k-means squared algorithm. Implement it with tests, from scratch. No sample data etc. In about 45 minutes. I was applying for an Android position. Still sticks with me to this day how cold the interviewer was. It's a great learning experience and has made me a better interviewer
Hands down my worst interview experience was one where I was grilled on exact versions of operating systems, compilers, and software I used. Then over the phone I was asked to implement some simple functions in C++ but the interviewer kept getting annoyed I'd use shorthand like "array of doubles" and wanted me to say it like I was dictating into a compiler! The interview was cut short after I made a few off by one mixups in the code, probably for the best...
My worst interview was some middling Canadian software shop that wouldn't let me use a Python IDE to implement a pagination function; like others, they wanted to do it in Notepad / Google Docs. I complained repeatedly and their defense was that "Amazon was using a similar process to find engineers". I asked if they were paying in Amazon stock. I did not get a call back, and, in retrospect, it was for the best.
What's interesting to me is that CS adjacent fields are going through the same teething pains as CS for how to conduct interviews. My background is in engineering and I'm familiar with the terrible experiences the article's author has had. At least now there is some awareness and acceptance that there are bad ways to conduct interviews and that stopping that just might be a good idea. Since then I've moved into the data science/ML world and its like starting at square zero. The field is broader and deeper than CS. Interviews are like being a ping pong ball being smashed on one side by someone with a PhD in physics and aggressively returned in kind by an economist.
My worst interview experience:
Company had their own custom hackerrank test set up. Timed. It failed to execute on my laptop. (Maybe browser plugins? I tried a different browser; still no joy) - I tried a few things, including using the browser debugger, and in the 30 minutes allotted, I couldn't succeed.
So I asked the recruiter to talk to the hiring manager to give me another shot with a different computer, and never got a response.
Mind you: they also had a horrible recruit process of filling out paperwork on their web site; including a form-entry version of your resume that you already uploaded. Plus various other forms to fill out and disclaimers to sign. Honestly, the worst I had ever encountered.
Since then, this company has had 3 different recruiters (one internal, two external) try to contact me for different positions, but the first one asked for the same process of going through their careers website and filling out all the forms again - even though my previous record was still there: because it was a different position, it had to be done again. That's when I bailed.
[+] [-] avl999|4 years ago|reply
My sanity check for any question I ask is- Is the question I'm asking something that someone in the past published a paper about? If so then that's probably not a good fit for a 45 minute whiteboarding interview. This question falls in that category. Generally those algorithms are complex enough that it is unrealistic to expect someone to get them right from first principles so at that point you are just selecting for people who just happened to have dealt with them, memorized them or implemented them recently.
I have a co-worker who used to ask people to past to parse and evaluate infix notation expressions in interviews (and there are companies that ask that question). Always stuck me as weird as multiple papers have been written about that problem, are you really expecting someone to implement a solution to a problem that people spend weeks (months?) thinking about before publishing? Could even Djikstra have come up with the Shunting Yard Algorithm in a 45 minute interview (with implementation on whiteboard) if that was his first exposure to the problem of expression parsing?
[+] [-] cowmoo728|4 years ago|reply
When I interviewed at FB, every round was something that I had drilled on leetcode or similar sites. Yes, the wording was changed and the problems were altered a bit, but they were the same algorithms. And there were also two "lightning" rounds of 15 minutes each to solve two simpler algorithms problems (maybe easy/medium difficulty on leetcode). This experience gave me the impression that facebook's goals in hiring were to select people who really wanted the job and could pass quizzes well.
[+] [-] lhorie|4 years ago|reply
One important thing you learn in interviewer workshops is to avoid asking questions with "aha" components, i.e. things that can only be solved if a very specific insight is known. This type of question is problematic because it falls victim to the fallacious assumption that a candidate that excels in one specific problem must necessarily excel at others that are in actuality, at best, only marginally related.
Instead, it is better to ask questions for which the solution can be arrived at with small increments in effort (e.g. maybe there's an obvious brute force solution and you start from there to discuss more optimal solutions, or maybe the candidate got stuck on some specific peculiarity and you can give a hint to unblock them and move on to another part of the problem to get more signal)
[+] [-] w0mbat|4 years ago|reply
It's way too complicated to code on a whiteboard. I would never have asked somebody that question at Google.
[+] [-] gh0std3v|4 years ago|reply
However, assuming that extensive knowledge of certain algorithms (like merge sort), data structures, or computational methods are necessary for a particular job, I think a better question to ask isn't "how do you implement merge sort" but instead to present the merge sort algorithm and then ask the interviewee how it works based on the code given. Obviously still not the best way to assess someone's skills, but I think it's better than just memorizing a bunch of algorithms without being able to explain how they work.
[+] [-] yodsanklai|4 years ago|reply
except that these things aren't research material anymore and are now taught at undergraduate level.
[+] [-] 908B64B197|4 years ago|reply
Also, is it a widely known algorithm? Because then I'm not measuring for programming ability; I'm measuring for rote memorization (there are people that will rote memorize all the sorting algos to be able to spit them out during interviews!).
Asking for a simply program like wc, in my opinion, gives a much better idea if someone can code (hint: there's not a single way of writing it and to define a word).
> I have a co-worker who used to ask people to past to parse and evaluate infix notation expressions in interviews
That's a cool problem to use. I wouldn't expect a perfect parser or even a working one but I would be curious to see how they approach the problem and what they end up writing.
[+] [-] kazinator|4 years ago|reply
A binary merge sort, if written recursively, is straightforward divide-and-conquer. The input list is divided into two halves, which are separately sorted via recursion, and then the sorted halves are merged to produce the sorted output.
The algorithm pops out of the definition. If you know the above definition (or the interviewer has provided it, which they should!) the rest is just an exercise which demonstrates that you can:
- completely analyze a problem's cases, including figuring out the existence of cases that are not spelled out in the description (like how to terminate the recursion)
- manipulate pointers
- decompose a problem into small, simple functions that you can separately reason about: (merging two lists, chopping a list in half, and such).
It's not such a bad interview question. I would actually tell all the candidates at least a day ahead of time that they will be implementing merge sort in C using a singly linked list during the interview, so they can study it all they want and rehearse coding it.
It's complicated enough that it can't just be regurgitated from memory by someone who doesn't know what the are doing. (Say, someone who had someone else write the code, and then tried to rote memorize it.) The memory has to be accompanied by understanding if the candidate is to reconstruct it with few or no flaws.
[+] [-] rrjanbiah|4 years ago|reply
[+] [-] WalterBright|4 years ago|reply
Wirth's "Pascal User Manual and Report" has a listing of a program on pg 75 that does just that. Except it emits the expressions in postfix form rather than evaluating them. It's 31 lines of code, including declarations and `end` statements.
K+R "The C Programming Language" has a desk calculator that evaluates postfix form on pages 74-75 which is about 60 lines of code including lines with just a {, and handles +-*/= including user interface and error checking.
[+] [-] rectang|4 years ago|reply
[+] [-] anonred|4 years ago|reply
Funnily enough, I also interviewed with the Apple Watch team around the same time and had a similar negative experience.
I was struggling with a problem on the whiteboard and paused to ask a question. Instead, one of the interviewers (it was a pair) turned to the other and said “I wish the Calendar complication on my watch would show when this meeting ends”
All the other interviewers that day were great, but it just takes a few bad apples… Even though it’s been years and I’ve had a nice tenure at FAANG, I’ll never consider joining Apple after that experience.
[+] [-] 908B64B197|4 years ago|reply
A candidate asking questions and trying to unblock himself is an extremely positive signal. It means they are capable of communicating and not start panicking when they hit a blocker.
[+] [-] kilbuz|4 years ago|reply
[+] [-] technofiend|4 years ago|reply
[+] [-] WalterBright|4 years ago|reply
[+] [-] strikelaserclaw|4 years ago|reply
[+] [-] lettergram|4 years ago|reply
Hell, in an interview I had this week I was given multiple incorrect answers to my clarification questions. Even when I said “I believe I answered it” the interviewer said “I don’t think so” until he finally looked up and was like “oh you got it”
I’m on zoom watching the interviewer text / look at other screens as I ask clarifying questions and they give dismissive answers “yea yea that sounds right, do that” while never looking up from their phone. Was a pretty “wtf” moment. I completed the interview, but I got the feeling the review will be subpar.
[+] [-] newsbinator|4 years ago|reply
"Sorry, it looks like I must have caught you at a bad time. If you have a fire to put out, I totally get it."
[+] [-] pezzana|4 years ago|reply
This article lays out the problem very well, but then again so to very many others which have appeared on HN over the years.
Why does this keep happening? I mean this at the most fundamental level.
Why waste time with programming puzzlers to begin with? Does the candidate's degree (assuming no job experience) not obviate the need for this kind of thing? Do past programming gigs not absolve them of the need to perform in a way they'll never be asked to perform on the job? Are CS departments so full of bullshitters that unless you sic your 10x devs on them to sniff out whether they can program their way out of a paper bag, your organization runs the risk of filling up with "C Players?"
I mean, what's really going on here?
[+] [-] ulkesh|4 years ago|reply
As an example -- in my line of work, one task we perform is processing files, some small, some medium, some very large; and I wanted to make sure a candidate understood the concept of Maps in order to perform O(n) to create a map and O(1) to look up items (generally speaking, I'm sure it's not exactly that in practice), which aide in efficient processing (the age old processor vs memory tradeoff). This particular candidate got everything I asked immediately, and the interview was very short. The person was made an offer soon after and has gone on to learn what we've done, adapt, and also teach us some things that have made the software better.
And the moment candidates grok the concepts I'm after, I confirm that's what I was after, and move on, trying not to waste too much time on any given item. And if they don't get the concepts after a short while, I try to lead them there and see how they react (is it a lightbulb moment or a confusion moment, etc). These are all signs for me to determine if someone is right for the position.
Interviewing is a 2-way street of respect. The interviewer often has all the perceived power, but in my experience, a good interviewer eschews that perception right from the get-go and lets the interviewee know that this is more of a discussion than any kind of trickery or exam, even when it contains coding questions.
This is why I will never interview for Google or any other company that has multi-stage interviews and also employs time-wasteful, and sometimes esoteric, methods such as "How many jelly beans fit in a school bus?"
[+] [-] tasty_freeze|4 years ago|reply
He went through the five interviews. After, we met for 20 minutes to express our thoughts. Pretty uniformly we agreed: the candidate was middling and we'd be better off waiting for someone better. We rejected him.
A day later the rejected candidate called my phone (how did he get it?) and said something like: "Hey, this is <candidate>. Why the hell wasn't I given an offer? The recruiter said that you (that is me, personally) had rejected me. Explain why." He insisted he had done great and we should reconsider.
The candidate hadn't reacted well to the rejection, and rather than being the firewall that shields the interviewers, the HR guy passed the buck and blamed me. We didn't reconsider, and I gave the HR guy hell about it.
[+] [-] RandyRanderson|4 years ago|reply
Maybe being put off by an ambiguous comment was why you didn't get the job? Did you consider maybe in his notes he might've said: "Smart guy but was put off by a single comment (a failed attempt at humour on my part). Probably not someone who would thrive in a lively atmosphere".
I had an interviewer ask a question and, not satisfied with the answer, get up and walk out. The other guy apologized and we had a good discussion after the other guy left.
[+] [-] pavlov|4 years ago|reply
This sounds like a cartoonish training example of the kind of subjective, possibly biased feedback that you absolutely shouldn’t be writing down as an interviewer.
[+] [-] Cyph0n|4 years ago|reply
A somewhat comparable analogy is your manager joking about firing you and then evaluating you negatively when you don’t like the joke.
[+] [-] taurath|4 years ago|reply
[+] [-] olivierlacan|4 years ago|reply
Good for you I guess, but maybe don't apply your own mental blueprint to the rest of the world. Recommending candidates have thicker skin isn't really great a way to improve hiring in general.
[+] [-] minimaxir|4 years ago|reply
[+] [-] mabbo|4 years ago|reply
[+] [-] seattle_spring|4 years ago|reply
He slammed (SLAMMED) his fist onto the table and yelled, "NO CODE!"
-----
Other bad experiences included Palantir telling me my onsite went really well, and that they'd like me to come in again to meet the hiring manager. Expecting to talk business, I instead was presented with 2 more algorithm questions. Those apparently went OK, so the next discussion with the recruiter yielded another "informal" (his words) meeting with 2 engineers via VC. Both ended up being 2 more DS/Algo questions.
-----
Another bad one I remember is a request to do a take-home coding test from Docusign (also circa 2012). They wanted me to program a "fully tested" elevator simulation using Stylus, Coffeescript, and Jade. I had never used any of these technologies, so I asked if I could write it in what I was familiar with (jQuery, Backbone, SCSS, ES5), which was denied. It would have taken me a full week to get up to speed on all of those technologies enough to submit a solution worthy of review. Absolutely ridiculous to ask a candidate to learn new frameworks just to complete the interview.
[+] [-] willio58|4 years ago|reply
This whole process is so broken. Great devs get passed up on for terrible devs who know how to grind Leetcode and the like. I hate having to grind leetcode for weeks just to end up getting asked obscure algorithm puzzle questions that I could never prepare for. And all for a 100% React job? Jesus.
[+] [-] klipklop|4 years ago|reply
[+] [-] mateo411|4 years ago|reply
It looks like these folks really bought into it.
[+] [-] AnotherGoodName|4 years ago|reply
It's obvious but geek culture sometimes need things like this explicitly stated.
[+] [-] strikelaserclaw|4 years ago|reply
[+] [-] akdas|4 years ago|reply
- Giving trick questions that have an "insight" moment, instead of one that has multiple answers, even partial answers to build off of.
- Not letting the candidate pick the language they're comfortable with. The candidate may even know the language they're asked to code in, but if they haven't been working with it recently, an interview is not the right time to pick it up again.
- Making the candidate nervous, both by not being helpful and by watching over them with unnecessary scrutiny.
- Looking for flaws instead of strengths.
People, myself included, are always talking about these problems, but companies have so much inertia, they are not evolving fast enough to solve these problems. No wonder tech companies are filled with people who, while capable, often fit a particular mold, and why we end up in situations where products don't reflect the needs of the market (because the people working on those products aren't representative of the market).
[0] https://hiringfor.tech/archive.html
[+] [-] strikelaserclaw|4 years ago|reply
[+] [-] andrewingram|4 years ago|reply
1. Being steered away from my answer for an algorithm problem, towards the interviewers preferred answer. When I reflected back on it later, I realised that my answer would have been more efficient for the specific problem asked, whilst the interviewers solution was for a more general version of the problem (which wasn't ever asked).
2. Being given feedback that I was weak on data structures, when there hadn't been any questions about data structures. I am weak on data structures though, so perhaps they just peered into my brain somehow.
3. Being told I wasn't suitable for remote positions because I was too verbose answering questions which were essentially trivia -- when I was intentionally trying to capture nuance because I didn't want to fall prey to trick questions.
1 and 2 were for the same company, but different stages.
[+] [-] hardwaregeek|4 years ago|reply
I recently applied and got an offer from a big N company. It took forever, easily three times the length of my other processes. I was not given any insight into my team beyond an overarching organization. The pay was not fantastic and they didn't honor my first location request. Why would I accept this? The pay I could have negotiated. But I'd still be put into a random, likely boring team in a city I didn't pick as my first choice. All to be able to work at a "Big N" company, when I've already had that experience. Maybe that works on some people but after the first Big N it's really not important.
[+] [-] hereforphone|4 years ago|reply
Bonus points for getting up while the interviewer is in mid-sentence and telling them it's not a fit.
[+] [-] nickff|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] Johnny555|4 years ago|reply
(while I meant "he" as a gender-neutral pronoun, sadly, nearly all of our senior tech candidates are male, but one bright spot is that we've got near gender parity with college interns which I hope means the job market is becoming more balanced)
[+] [-] ramphastidae|4 years ago|reply
[+] [-] milofeynman|4 years ago|reply
This should be an entertaining thread.
[+] [-] baskethead|4 years ago|reply
[+] [-] lfowles|4 years ago|reply
[+] [-] willhslade|4 years ago|reply
[+] [-] monkeybutton|4 years ago|reply
[+] [-] Pokepokalypse|4 years ago|reply
So I asked the recruiter to talk to the hiring manager to give me another shot with a different computer, and never got a response.
Mind you: they also had a horrible recruit process of filling out paperwork on their web site; including a form-entry version of your resume that you already uploaded. Plus various other forms to fill out and disclaimers to sign. Honestly, the worst I had ever encountered.
Since then, this company has had 3 different recruiters (one internal, two external) try to contact me for different positions, but the first one asked for the same process of going through their careers website and filling out all the forms again - even though my previous record was still there: because it was a different position, it had to be done again. That's when I bailed.