My worst tech interview experience(jessesquires.com)
jessesquires.com
My worst tech interview experience
https://www.jessesquires.com/blog/2021/12/01/my-worst-tech-interview-experience/
274 comments
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.
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.
One bit of dirty laundry to keep in mind with FAANG and friends is that the interview process is somewhat self-selecting. Often times, the very people that crammed leetcode in the hopes of landing FAANG roles are the ones interviewing candidates three months later. So there this sort of twisted feedback cycle where the interviewers think that leetcode solving ability is a sort of badge of honor or whatever.
Obviously not all interviewers are like that, and at more senior levels, interviewers do place more emphasis on other criteria, but for entry/L4/L5-ish roles, it's a pretty rampant thing.
Obviously not all interviewers are like that, and at more senior levels, interviewers do place more emphasis on other criteria, but for entry/L4/L5-ish roles, it's a pretty rampant thing.
I got asked to parse infix notation and figured it out in the 45 minutes despite having no prior experience with parsing anything more complicated than CSV. I am not bragging or anything, I just know these discussions are biased towards kvetching so someone has to weigh in for it being possible to accomplish. My field is not computer science and if anything I'm the perfect example of who the infix notation question should be biased against.
To be fair the interviewer described my performance as "muscling through it" (exact phrasing changed to protect the innocent) so take it as you will. :)
I am aware that there is no way to write this comment without sounding like a boast, but that's just more reason to write it because there are probably a large number of people with the same story who can't balance out the discussion by telling it.
To be fair the interviewer described my performance as "muscling through it" (exact phrasing changed to protect the innocent) so take it as you will. :)
I am aware that there is no way to write this comment without sounding like a boast, but that's just more reason to write it because there are probably a large number of people with the same story who can't balance out the discussion by telling it.
To be fair the interviewer described my performance as "muscling through it" (exact phrasing changed to protect the innocent) so take it as you will.
And we're supposed to be desperately anxious to work for companies filled with people like that?
And we're supposed to be desperately anxious to work for companies filled with people like that?
This all started back in the 90´s with companies like Microsoft, but at that time the questions were somewhat reasonable, and just reading something like Programming Pearls was most of what you needed to know.
But I suspect what has happened, is that as those hired by this method got promoted, they started asking harder questions... and that has over time escalated into the current situation which has become somewhat ridiculous in terms of pre-study, etc.
But I suspect what has happened, is that as those hired by this method got promoted, they started asking harder questions... and that has over time escalated into the current situation which has become somewhat ridiculous in terms of pre-study, etc.
I thought M$ was asking questions about how many piano tuners does it take to fit a manhole cover in MTN fugi or something like that?
I just remember too many dumb questions like that and am a bit salty.
I just remember too many dumb questions like that and am a bit salty.
> My impression of the facebook interview experience was that it is specifically selecting people that were calm under pressure and well rehearsed.
Yes, the more stressed / slow thinker you are, and the more work you need to put to prepare these interviews. It's not uncommon for people to practice for years.
I don't think these companies exactly want this type of profile, but when you interview 10000s of people, you need some consistent criteria so that all candidates are treated equally. With that constraint, I don't think you can find a better interviewing system.
Yes, the more stressed / slow thinker you are, and the more work you need to put to prepare these interviews. It's not uncommon for people to practice for years.
I don't think these companies exactly want this type of profile, but when you interview 10000s of people, you need some consistent criteria so that all candidates are treated equally. With that constraint, I don't think you can find a better interviewing system.
If you can crank out some moderately complicated algorithms, even having rehearsed them, and get all the little details right, like all the cases that occur, that does show you kind of know what you're doing.
Someone without the proper CS/programming background who is just trying to rote memorize will screw up the details, and not be able to explain anything if asked about it: like what is the purpose of that line of code?
Only problem is, even if this interview question is good at testing that which it is testing, it might not be selecting people along the right dimensions in terms of being suited for the job. It's not probing all the attributes of a software engineer.
Five candidates, A, B, C, D and E have done equally well on the exercise, excellent in fact, and are hired.
Yet, in actual work, things go funny.
A doesn't seem to believe in testing. Deliveries are sloppy and break things all the time. A is proud of her skills and treats criticism of their code as an insult.
B has never heard the words "version" and "control" in one sentence. B works on an out-of-date version of the code to make a change, and then follows the Wiki instructions for getting a fresh checkout (which pulls the latest baseline) and then just copies their previously changed files into the new checkout. Their code submission therefore reverts numerous changes from other people (incompletely: just in those files), while asserting their own changes. On top of that, B makes gratuitous whitespace changes, doesn't follow any consistent coding standard (never mind the prescribed one), and randomly fixes things he sees wrong that do not relate to the topic of the change.
C cannot handle changes in requirements. Even after code base has undergone many changes, C keeps thinking in the same concepts from when the code was two months old and C had been mostly working alone on that code, knowing everything about it. C's ideas about making changes no longer fit the new code. E.g. C cannot remember that some logic is now distributed, running in several places at once, because that's not how it once was, and consistently forgets that aspect.
D cannot say no to any new task. Whenever someone talks to D, D gets distracted and excited and starts looking into what that person was talking about, and doing work on it. Whenever D gets stuck on something, D easily finds something else, and forgets about being stuck, or to report having been stuck. D leaves numerous tickets in an in-progress state, and that list just grows over time.
E is simply lost in any large project. E has done nothing but programming challenges under 1000 lines of code. E has no skills with regard to navigating a large code tree and understanding the structure of something made of tends of thousands of lines (or orders of magnitudes more). E gets paralyzed when faced with making a change to a large system that will involve making some small changes to eight or nine files. But have you seen E's Tetris in five lines of code?
Someone without the proper CS/programming background who is just trying to rote memorize will screw up the details, and not be able to explain anything if asked about it: like what is the purpose of that line of code?
Only problem is, even if this interview question is good at testing that which it is testing, it might not be selecting people along the right dimensions in terms of being suited for the job. It's not probing all the attributes of a software engineer.
Five candidates, A, B, C, D and E have done equally well on the exercise, excellent in fact, and are hired.
Yet, in actual work, things go funny.
A doesn't seem to believe in testing. Deliveries are sloppy and break things all the time. A is proud of her skills and treats criticism of their code as an insult.
B has never heard the words "version" and "control" in one sentence. B works on an out-of-date version of the code to make a change, and then follows the Wiki instructions for getting a fresh checkout (which pulls the latest baseline) and then just copies their previously changed files into the new checkout. Their code submission therefore reverts numerous changes from other people (incompletely: just in those files), while asserting their own changes. On top of that, B makes gratuitous whitespace changes, doesn't follow any consistent coding standard (never mind the prescribed one), and randomly fixes things he sees wrong that do not relate to the topic of the change.
C cannot handle changes in requirements. Even after code base has undergone many changes, C keeps thinking in the same concepts from when the code was two months old and C had been mostly working alone on that code, knowing everything about it. C's ideas about making changes no longer fit the new code. E.g. C cannot remember that some logic is now distributed, running in several places at once, because that's not how it once was, and consistently forgets that aspect.
D cannot say no to any new task. Whenever someone talks to D, D gets distracted and excited and starts looking into what that person was talking about, and doing work on it. Whenever D gets stuck on something, D easily finds something else, and forgets about being stuck, or to report having been stuck. D leaves numerous tickets in an in-progress state, and that list just grows over time.
E is simply lost in any large project. E has done nothing but programming challenges under 1000 lines of code. E has no skills with regard to navigating a large code tree and understanding the structure of something made of tends of thousands of lines (or orders of magnitudes more). E gets paralyzed when faced with making a change to a large system that will involve making some small changes to eight or nine files. But have you seen E's Tetris in five lines of code?
> B works on an out-of-date version of the code to make a change, and then follows the Wiki instructions for getting a fresh checkout (which pulls the latest baseline) and then just copies their previously changed files into the new checkout.
Do people like that ever make it into Google, Facebook etc. or is it purely a hypothetical?
Do people like that ever make it into Google, Facebook etc. or is it purely a hypothetical?
They do, we had plenty of dead weight at Google, usually acquihires.
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)
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)
The "aha moment" is also known as the eureka effect. Psychologists call this "insight problem solving", which is terrible for interviewing since like you said since it isn't a problem that you can build up towards solving. As a teacher, I try to make sure my assignments/quizzes don't fall victim of this.
For anyone interested, there are a lot of interesting studies on the topic if you search on Google Scholar. You've probably already seen matchstick arithmetic problems before (i.e., move a single matchstick to make the equation valid).
For anyone interested, there are a lot of interesting studies on the topic if you search on Google Scholar. You've probably already seen matchstick arithmetic problems before (i.e., move a single matchstick to make the equation valid).
It never ceases to amaze me that a profession full of people that studied something called “computer science” is also filled with people that refuse to read the literature when it comes to hiring and instead lean on gut feelings, anecdotes, and cargo cult-ing.
> refuse to read the literature ... and instead lean on gut feelings, anecdotes, and cargo cult-ing
I mean, if it works for programming...
I mean, if it works for programming...
I've researched a lot about this since I've had to do hiring, but I haven't been lucky enough to find anything collectively definitive or comprehensive enough to describe as "the literature." Most of it leans towards "what not to do," which is helpful but leaves some gaps. What do you recommend?
I got asked to whiteboard the Dijkstra Shunting Yard Algorithm at TripAdvisor in Palo Alto. I didn't get the job, which I could have done in my sleep.
It's way too complicated to code on a whiteboard. I would never have asked somebody that question at Google.
It's way too complicated to code on a whiteboard. I would never have asked somebody that question at Google.
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.
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.
except that these things aren't research material anymore and are now taught at undergraduate level.
That's the point. No one is solving the problem, they're regurgitating knowledge.
If you care is someone has completed a Computer Science degree, ask to see their resume. If you care if they actually learned the material, ask to see their GPA.
If you care is someone has completed a Computer Science degree, ask to see their resume. If you care if they actually learned the material, ask to see their GPA.
Neither one of those things are reliable sources of information across candidates or universities.
Especially when you consider applications from all over the world.
But a 45m technical interview is?
> 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.
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.
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.
FWIW, I have created a tracker under the Open Market Research repo to track such broken hiring and fake job posts https://github.com/OpenMarketResearch/Labs/issues/new?labels...
> parse and evaluate infix notation expressions
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.
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.
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.
That's incredibly rude.
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.
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.
Any (surely) dude who calls a feature on his glorified step counter a "complication" has already let you know everything you need to know about them.
Complication is a well-established term in the watch industry. https://en.wikipedia.org/wiki/Complication_(horology)
A complication is a watch related term for any feature that doesn't tell the time, and predates electronic watches.
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.
The correct riposte is to say "your watch team clearly could use my expertise!"
maybe the steve jobs asshole ethos permeates that company
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.
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.
You can comment on it.
"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."
"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."
I had an in-person interview where I should have said that, multiple times.
In retrospect I probably will, definitely better to do that than waste a whole day due to one distracted interviewer
[deleted]
> 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 mean, what's really going on here?
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?
I used to feel like you and ask the same questions until recently when I read someone on HN saying these interviews are meant to see how a person handles stress. Then it clicked for me.
I've done pretty well at interviews despite being terrible at white board exercises because my personality is such that I treat these interviews casually. It's not that important in the larger scheme of things that I get this particular job, I'm looking at the interviewers as much as they are looking at me to see if I could work with them and I'll often joke around and keep it light hearted, even when failing a white board exercise.
The interviewers know the work culture and are looking for someone that can fit. In the case presented in this blog post, the writer could not handle a small joke about the Swift language. The interviewer probably knew the team like to joke around and tease, so this person was not a good fit. I think it's really that simple. I really doubt the interviewer thought the person was not technically qualified.
In one case, I was in a particularly light hearted mood and I joked throughout the entire interview. I believe to this day I was hired to lighten up the mood of the team, which turned out to be a very serious and gloomy bunch.
I've done pretty well at interviews despite being terrible at white board exercises because my personality is such that I treat these interviews casually. It's not that important in the larger scheme of things that I get this particular job, I'm looking at the interviewers as much as they are looking at me to see if I could work with them and I'll often joke around and keep it light hearted, even when failing a white board exercise.
The interviewers know the work culture and are looking for someone that can fit. In the case presented in this blog post, the writer could not handle a small joke about the Swift language. The interviewer probably knew the team like to joke around and tease, so this person was not a good fit. I think it's really that simple. I really doubt the interviewer thought the person was not technically qualified.
In one case, I was in a particularly light hearted mood and I joked throughout the entire interview. I believe to this day I was hired to lighten up the mood of the team, which turned out to be a very serious and gloomy bunch.
> Does the candidate's degree (assuming no job experience) not obviate the need for this kind of thing?
I've met people with degrees who can't program out of a wet paper bag. And also people without a degree who can program circles around anyone. It only seems to be an indicator of your ability to finish a long term project, unless it's a top school. Then it's a slightly more positive indicator.
> 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?
When I was doing interviews for Netflix for Senior Engineers, I always asked FizzBuzz on the phone screen. These were all people who had at least five years of programming experience on their resume with titles like "Senior Engineer".
50% of them were unable to do the assignment in any language with unlimited time.
So it appears that a resume is not sufficient either.
I hate puzzlers and quizzers and never use them (other than FizzBuzz, which frankly anyone who can code should be able to do). But I don't know what exactly we can replace them with.
I personally just ask the person more general questions to understand their depth of knowledge and then explain what the work will entail and ask them if they think they can handle that. Then I hire them and give them work and let them go (or let them quit on their own) if they can't handle the work.
I've met people with degrees who can't program out of a wet paper bag. And also people without a degree who can program circles around anyone. It only seems to be an indicator of your ability to finish a long term project, unless it's a top school. Then it's a slightly more positive indicator.
> 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?
When I was doing interviews for Netflix for Senior Engineers, I always asked FizzBuzz on the phone screen. These were all people who had at least five years of programming experience on their resume with titles like "Senior Engineer".
50% of them were unable to do the assignment in any language with unlimited time.
So it appears that a resume is not sufficient either.
I hate puzzlers and quizzers and never use them (other than FizzBuzz, which frankly anyone who can code should be able to do). But I don't know what exactly we can replace them with.
I personally just ask the person more general questions to understand their depth of knowledge and then explain what the work will entail and ask them if they think they can handle that. Then I hire them and give them work and let them go (or let them quit on their own) if they can't handle the work.
I don't think that programming puzzles are the best way to divine better information in this area. But yes, there's a ton of people looking for a programming job that both have a lot of experience on paper and can't code their way out of a wet paper bag. It seems you can have very long stretches in a large company where you do negative work.
Best way I've found is to talk to them about their experience, sort of post mortem style. Pretty much everyone can talk about their experience in some respects, even those working on classified projects; you just need to respect their boundaries.
Best way I've found is to talk to them about their experience, sort of post mortem style. Pretty much everyone can talk about their experience in some respects, even those working on classified projects; you just need to respect their boundaries.
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?"
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?"
I wholeheartedly agree with your idea of having a 2-way street of respect, and treating interviews less like interrogations and more like discussions. It certainly feels more natural that way, and puts less pressure on the interviewee.
Regarding Google specifically, I just interviewed there about 2 weeks ago, and although I didn't get the job, I will say I felt very respected, and with the exception of maybe one interview, thought everything felt like a discussion. There were no trick questions, everything was fairly straightforward. Basically a leetcode medium/hard for the 4 technicals and just discussing my experiences in various situations for the "Googleyness" interview.
I have heard similar stories about Google using these trick questions, but from what I understand these were mistakes made in the earlier days of the company and have been effectively phased out, although that is purely speculative.
Regarding Google specifically, I just interviewed there about 2 weeks ago, and although I didn't get the job, I will say I felt very respected, and with the exception of maybe one interview, thought everything felt like a discussion. There were no trick questions, everything was fairly straightforward. Basically a leetcode medium/hard for the 4 technicals and just discussing my experiences in various situations for the "Googleyness" interview.
I have heard similar stories about Google using these trick questions, but from what I understand these were mistakes made in the earlier days of the company and have been effectively phased out, although that is purely speculative.
>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?"
I said this once upon a time. then I realized I like money and I'm willing to dance a jig if thats what will get me beaucoup RSUs to fund my personal startup venture
I said this once upon a time. then I realized I like money and I'm willing to dance a jig if thats what will get me beaucoup RSUs to fund my personal startup venture
I get paid well where I'm at right now. I live a pretty good life. I don't begrudge anyone who works for Google or any other tech giant, I simply set my own standards and I live by them. I find it is a waste of time for me to interview at places that try those kinds of gimmickry. And from what others are saying, it looks like Google doesn't do that anymore nor does it sound like it was widespread, so it may have been simply anecdotal accounts I remember reading.
> I will never interview for Google or any other company that
> asks questions like "How many jelly beans fit in a school bus?"
Good to hear. They have done that in the past, though, I've read a few first-hand accounts of it (and sadly I cannot find them now so take it with a grain of salt, of course). Perhaps it was just early-days.
Yes, that's the circa 2005 version of what we have today.
If you at least tried you could still get an offer however, unlike today, where the answer must be approaching perfection and timely. Because they are a lot more interested in exposing impostors both real and imagined than hiring.
If you at least tried you could still get an offer however, unlike today, where the answer must be approaching perfection and timely. Because they are a lot more interested in exposing impostors both real and imagined than hiring.
> 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?"
Good news: they don't do that any more.
Bad news: you still need to practice the fermi estimation techniques that question employs, but also need to know like, the details of every paper they've published on distributed systems, and bring your own heuristics about computers and email in order to determine how big a GFS cluster you need to launch gmail.
Is that better? I'm not so sure.
Good news: they don't do that any more.
Bad news: you still need to practice the fermi estimation techniques that question employs, but also need to know like, the details of every paper they've published on distributed systems, and bring your own heuristics about computers and email in order to determine how big a GFS cluster you need to launch gmail.
Is that better? I'm not so sure.
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.
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.
Out of curiosity, what made him middling and not good?
Surely someone at your org could have determined that it's better to stop wasting each other's time before going through 5 interviews?
Sounds like there's more to the story than you're having us believe and the candidate had very good reasons to be upset (the exact wording and tone he used was not appropriate). If he insisted he had done great, I venture to say that he was led on during interviews and not given honest feedback.
Surely someone at your org could have determined that it's better to stop wasting each other's time before going through 5 interviews?
Sounds like there's more to the story than you're having us believe and the candidate had very good reasons to be upset (the exact wording and tone he used was not appropriate). If he insisted he had done great, I venture to say that he was led on during interviews and not given honest feedback.
What made him middling? It was 15 years ago so I don't recall the details. The usual reasons are things like: didn't answer some questions well, or maybe their resume oversold their accomplishments (eg, "Proficient in verilog, C, C++, pascal, fortran, javascript, java" "OK, describe one of the programs you have written in java." "Well, uh, this one time there was this program that was already written, and I had to add some better error messages when it received bad input.")
Why did he go through the full round of interviews? Because (1) he was referred by an existing employee so interviewer were inclined to give him the benefit of the doubt, and (2) he wasn't terrible, just nothing special; it sometimes happens that one person gets a low impression and the others think they are great and we hire them anyway.
You surmise I must be telling part of the story because his reaction doesn't fit my description of the process. Yes, that is exactly the point of telling the story -- his response wasn't appropriate. Had I felt he had a reason to react that way, I wouldn't be retelling the story.
Why did he go through the full round of interviews? Because (1) he was referred by an existing employee so interviewer were inclined to give him the benefit of the doubt, and (2) he wasn't terrible, just nothing special; it sometimes happens that one person gets a low impression and the others think they are great and we hire them anyway.
You surmise I must be telling part of the story because his reaction doesn't fit my description of the process. Yes, that is exactly the point of telling the story -- his response wasn't appropriate. Had I felt he had a reason to react that way, I wouldn't be retelling the story.
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.
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.
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.
A somewhat comparable analogy is your manager joking about firing you and then evaluating you negatively when you don’t like the joke.
As an interviewer, I sometimes make comments like that and it isn’t negative or even a joke. Just trying to make the interviwee feel comfortable
“Oh hey jumping between languages is hard, looks like you’re thinking in Swift right now, no worries about fumbling on syntax happens all the time”
“Oh hey jumping between languages is hard, looks like you’re thinking in Swift right now, no worries about fumbling on syntax happens all the time”
That sounds completely fine to me. At the end of the day, how you phrase things makes a huge difference, and even more so in stressful situations imo.
Would you spell out for us what is unambiguously Wrong about "you must be writing a lot of Swift"? A charitable interpretation could be this is a shallow joke about semicolons, that could be safe for lightening things up in an interview, especially when the audience is known to be familiar with Swift.
My impression from the OP is that they were out of sync with their interviewer, they didn't "click". This is something that happens with humans. The interviewer may have detected this dynamic, and made the joke to break the ice. Obviously it backfired, but with another candidate perhaps it could have saved the interview?
Separately, what do folks thinks about the importance of humor on teams, and the degree to which it's acceptable to screen for sense of humor as part of interviews?
My impression from the OP is that they were out of sync with their interviewer, they didn't "click". This is something that happens with humans. The interviewer may have detected this dynamic, and made the joke to break the ice. Obviously it backfired, but with another candidate perhaps it could have saved the interview?
Separately, what do folks thinks about the importance of humor on teams, and the degree to which it's acceptable to screen for sense of humor as part of interviews?
Can you explain how making this joke would have saved the interview?
Here is how I see it. At best, you interrupt a candidate in the middle of a technical interview to make a joke. At worst, you ruin the interview experience for the candidate. To me, the cost/benefit is clear cut.
During a technical interview, you are evaluating the candidate’s technical knowledge. You are not there to become friends. There will be time for that after the candidate goes through the interview process.
Here is how I see it. At best, you interrupt a candidate in the middle of a technical interview to make a joke. At worst, you ruin the interview experience for the candidate. To me, the cost/benefit is clear cut.
During a technical interview, you are evaluating the candidate’s technical knowledge. You are not there to become friends. There will be time for that after the candidate goes through the interview process.
I'm pretty sure during an interview once someone made a very similar joke when I'd written using Rust syntax instead of Javascript. I thought it was funny and thanked them for tactfully pointing out my syntax errors and confirmed I had been writing Rust a lot recently.
The only other choices for the interviewer are to bluntly say "you missed using semicolons" or to not say anything and be left to wonder if the person knows how to really write in C. The author of this post seems to think even considering any other choice than the last is rude since "whiteboard code doesn't compile so semicolons are syntactic sugar".
But if it does matter, baking in some understanding of the charitable reasons why (that the interviewee is proficient at multiple languages, especially in the popular ones at Apple like Swift) is actually the nicest thing the interviewer could have done.
The post author seems to me hostile to being corrected. Given that every code review I've been in requires being corrected dozens of times about errors large and small, I wouldn't want to have to deal with their uncharitable attitude towards feedback from coworkers/collaborators.
The only other choices for the interviewer are to bluntly say "you missed using semicolons" or to not say anything and be left to wonder if the person knows how to really write in C. The author of this post seems to think even considering any other choice than the last is rude since "whiteboard code doesn't compile so semicolons are syntactic sugar".
But if it does matter, baking in some understanding of the charitable reasons why (that the interviewee is proficient at multiple languages, especially in the popular ones at Apple like Swift) is actually the nicest thing the interviewer could have done.
The post author seems to me hostile to being corrected. Given that every code review I've been in requires being corrected dozens of times about errors large and small, I wouldn't want to have to deal with their uncharitable attitude towards feedback from coworkers/collaborators.
Tone and timing matters. If the interviewer had interrupted the candidate's train of thought, or spoken it during a particularly tense moment, it can really throw off their game.
Code reviews after already being hired and accepted into a company are not comparable to interviews during the application process, when the specter of rejection still looms.
Code reviews after already being hired and accepted into a company are not comparable to interviews during the application process, when the specter of rejection still looms.
First, would you respond to my question? :) In the case of the other commenter's suggested joke, you said "That sounds completely fine to me", so I genuinely want to know why one joke is completely fine and the other falls into the bucket
"If you’re making jokes like this in an interview, you shouldn’t be an interviewer".
Anyhow, to answer you, on both sides of interviews, I've experienced bad chemistry early in the session. Could be any number of factors, even just one of the two of us getting out on the wrong side of bed that morning. I sometimes will make a joke to lighten things up and get things back on track. Sometimes it helps, sometimes not, but I like to feel over time I am learning better how to interact with humans, and improving my odds, leading to more positive interview experiences and less wasted time. Things are never "strictly technical" with humans.
(all that said, to be clear, I have never brought up the candidate's sense of humor in providing feedback, although I don't see a problem doing so if humor is in the team's values manifesto or the job description, and we've agreed on a legitimate way to screen for it (seems hard!). Curious to learn others' thoughts on this subject!)
Anyhow, to answer you, on both sides of interviews, I've experienced bad chemistry early in the session. Could be any number of factors, even just one of the two of us getting out on the wrong side of bed that morning. I sometimes will make a joke to lighten things up and get things back on track. Sometimes it helps, sometimes not, but I like to feel over time I am learning better how to interact with humans, and improving my odds, leading to more positive interview experiences and less wasted time. Things are never "strictly technical" with humans.
(all that said, to be clear, I have never brought up the candidate's sense of humor in providing feedback, although I don't see a problem doing so if humor is in the team's values manifesto or the job description, and we've agreed on a legitimate way to screen for it (seems hard!). Curious to learn others' thoughts on this subject!)
Sure! We only have the candidate's perspective, but it appears that the candidate:
1) felt that the tone of the interviewer was negative
2) was in the middle of writing their solution
3) did not actively ask for feedback on syntax
Point #1 is subjective, but an interviewer should err on the side of caution when making curt remarks like this. Taken together, points #2 and #3 are important too: as an interviewer, you should know when (or even whether or not) to provide feedback.
As for why I believe the comment above phrased it better:
1) the interviewer is clearly acknowledging that it can be challenging to use a different language in an interview
2) the interviewer is clearly stating that the syntax mistakes being made are minor and nothing to worry about
Personally, I would still avoid making this kind of comment unless prompted by the candidate - e.g., in reply to "I think I might be making a few mistakes with syntax here". I would also avoid providing any feedback.
I also agree that an interview is not purely technical: there are other _passive_ signals you can use to build a better picture. I don't see how you would be able to judge sense of humor reliably in an interview setting, though.
1) felt that the tone of the interviewer was negative
2) was in the middle of writing their solution
3) did not actively ask for feedback on syntax
Point #1 is subjective, but an interviewer should err on the side of caution when making curt remarks like this. Taken together, points #2 and #3 are important too: as an interviewer, you should know when (or even whether or not) to provide feedback.
As for why I believe the comment above phrased it better:
1) the interviewer is clearly acknowledging that it can be challenging to use a different language in an interview
2) the interviewer is clearly stating that the syntax mistakes being made are minor and nothing to worry about
Personally, I would still avoid making this kind of comment unless prompted by the candidate - e.g., in reply to "I think I might be making a few mistakes with syntax here". I would also avoid providing any feedback.
I also agree that an interview is not purely technical: there are other _passive_ signals you can use to build a better picture. I don't see how you would be able to judge sense of humor reliably in an interview setting, though.
Thank you! Not much to argue with, rather just nodding my head. I hope one of us interviews the other some day, and that we have a chance to debrief after.
A positive reading is “you must be coding Swift a lot lately, I acknowledge switching languages is hard and won’t fault you for it”.
A negative reading is “you are screwing this up enough for me to comment, you need to justify why”
If it’s intended to be reassuring then phrasing it so it’s clearly not a criticism is better. If it’s intended as a criticism then phrasing it clearly is also better.
The way I can see it being a joke, as claimed, is insultingly. Like a dentist watching a trainee dentist doing a filling and saying “you must have been doing masonry work lately”. Haha but the subtext is “you’re really doing a bad job of this”.
A negative reading is “you are screwing this up enough for me to comment, you need to justify why”
If it’s intended to be reassuring then phrasing it so it’s clearly not a criticism is better. If it’s intended as a criticism then phrasing it clearly is also better.
The way I can see it being a joke, as claimed, is insultingly. Like a dentist watching a trainee dentist doing a filling and saying “you must have been doing masonry work lately”. Haha but the subtext is “you’re really doing a bad job of this”.
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.
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.
An incredible display of disrespect? It might be rude, but that’s about it. Depending on the tone of voice, it could have been intended as a way to relieve the author’s tension.
It does sound a bit annoying, but if that is the author’s worst interviewing experience, it’s not that bad.
It does sound a bit annoying, but if that is the author’s worst interviewing experience, it’s not that bad.
On reading it my thought was the interviewer was making a small joke to put the author at ease: "Ah, you've forgotten some semis, you're probably writing a lot of swift at the moment, it's okay". But he was in the room and I wasn't, so I can only trust his interpretation.
i'm not sure you can jump to that conclusion either. there takes a certain level of maturity both emotional and financial at certain skill levels. a psychologist once pointed out to me that actors are able to take their nervousness and translate it into energy to use in the moment.
at a point in my career i faced a similar dilemma but handled it completely differently than i had earlier. someone made a snide comment "but why would you use bash for this?" and i was able to take it in stride and the result of that comment got me the job. but at the start of my career i may have reacted negatively, i may have clammed up and stammered my way through the rest of the interview etc (i didn't get those jobs). could you imagine being in front of a C-level exec or a $300M customer and being discombobulated?
no one wants to hire an insecure pre-sales engineer etc
EDIT: i'm assuming engineering levels beyond senior. my past experiences have been around principal/architect roles which require a 'tough skin'. i would not expect rude remarks to a SE1 or SE2 and if that was the role, i would leave flustered with a bad taste in my mouth as well
at a point in my career i faced a similar dilemma but handled it completely differently than i had earlier. someone made a snide comment "but why would you use bash for this?" and i was able to take it in stride and the result of that comment got me the job. but at the start of my career i may have reacted negatively, i may have clammed up and stammered my way through the rest of the interview etc (i didn't get those jobs). could you imagine being in front of a C-level exec or a $300M customer and being discombobulated?
no one wants to hire an insecure pre-sales engineer etc
EDIT: i'm assuming engineering levels beyond senior. my past experiences have been around principal/architect roles which require a 'tough skin'. i would not expect rude remarks to a SE1 or SE2 and if that was the role, i would leave flustered with a bad taste in my mouth as well
How is a lame joke about Swift an "incredible display of disrespect"?
Dial the rhetoric down, we can't really read the "context" in which this line was delivered by the interviewer. Glib? Sure. Incredible display of disrespect? Give me a break.
Then that's a massive failure on the interviewer's side that they cannot respect that the candidate may be under anxiety.
I don't want to work in your "lively atmosphere". It sounds pretty toxic.
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.
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.
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.
The System Design question where you design an elevator system, was in vogue around 2015. Two different companies asked me the same question.
It looks like these folks really bought into it.
It looks like these folks really bought into it.
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.
It's obvious but geek culture sometimes need things like this explicitly stated.
anyone can appear smart if they know the question beforehand.
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).
[0] https://hiringfor.tech/archive.html
- 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
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.
A few of my interview experiences from last year:
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.
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 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.
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).
It is possible to stand up and tell the interviewer (while he's in mid-sentence) that it's not a fit, politely.
Maybe we have different ideas of what qualifies as polite, but standing up and interrupting someone mid-sentence seems rude to me.
[deleted]
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)
(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)
They/them is what you’re looking for: https://en.m.wikipedia.org/wiki/Singular_they
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
This should be an entertaining thread.
This should be an entertaining thread.
If Google re-interviewed all their current programmers, what percentage of them would pass the phone screen and onsites and get another job offer?
This is a very good question.
I work in a Wall Street trading company. Up til about 6 years ago, I was actively involved in recruiting tech staff and defining our tech recruitment process.
I’ve since changed roles, but was recently asked to sit in on an interview.
Wow, how things have changed. I seriously doubt I would be successful going through the current recruitment process.
Any why? Focus on whiteboard programming with questions that far exceed the requirements for the day-to-day job.
Somewhere along the line, egos took over and we have a bunch of devs on an ego trip to prove how smart they are.
I work in a Wall Street trading company. Up til about 6 years ago, I was actively involved in recruiting tech staff and defining our tech recruitment process.
I’ve since changed roles, but was recently asked to sit in on an interview.
Wow, how things have changed. I seriously doubt I would be successful going through the current recruitment process.
Any why? Focus on whiteboard programming with questions that far exceed the requirements for the day-to-day job.
Somewhere along the line, egos took over and we have a bunch of devs on an ego trip to prove how smart they are.
I thought about this a lot at my former job. When I first applied, we were 30 people strong, but 4 years later we were 150 people and had hired veterans from the NSA/FBI/NASA/FB/Google etc. I often thought, I definitely would not be hired if I re-applied right now.
Amazon explicitly engineers this into the interview process via “bar raising”. You have to be better than the bottom half of people who hold the position to get hired. If Google is implicitly doing the same thing, I’d guess the same 40-60% that was mentioned in the thread.
I think most (entry to 5 years of experience at least) people who work at FAANG companies spend dedicated time studying for interviews. They also know exactly what their company is looking for - leadership principles for Amazon, for example. If you gave current FAANG engineers a month to prepare, I think 80% of them would reclaim their jobs. If you gave them no time to prepare, I think less 30% of them would reclaim their jobs.
The ability to solve contrived coding problems is a muscle that needs to be exercised, even when one does actual programming for their job every day. I'm guessing most people don't practice interviews when they aren't expecting to interview, so only a small percentage would retain enough to pass a loop.
The ability to solve contrived coding problems is a muscle that needs to be exercised, even when one does actual programming for their job every day. I'm guessing most people don't practice interviews when they aren't expecting to interview, so only a small percentage would retain enough to pass a loop.
[deleted]
I think almost all would pass the phone screen and maybe less than 90% would pass the interview again.
It would be actually great if they did exactly that, as an anonymized experiment somehow. My guess would be 40-60%.
What percentage would pass the interviews but knowing what they know now about working at Google, would take an offer at another company?
[deleted]
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...
What?? You had to do a coding interview over the phone?? That’s probably the craziest story on this page!
I actually did one of these as well. We couldn't get the video call to work, so the interviewer ended up having me write the code down, and then read it to him over the phone.
At the time if felt pretty dumb (and still kinda does), but he was fairly reasonable about it, and most of the back and forth was me describing the algorithm to him.
At the time if felt pretty dumb (and still kinda does), but he was fairly reasonable about it, and most of the back and forth was me describing the algorithm to him.
I'm really not sure what the purpose of the call was! It was my first scheduled contact with the company after sending in my resume, but it was directly with the hiring manager and he got right into writing code over the phone. I've checked their Glassdoor page again this year and my experience seems common.
I did a coding interview over the phone with Google. This was around 2006 maybe 2007. I did it in my car with a notebook in my lap. I don't remember the question but it was "leetcodish"
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.
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.
I've seen a lot of companies that ask for a copy of your CV and also ask you to fill out a form with fields for all the information on a typical resume. That's a red flag that a company has some bad process going on behind the scenes.
I presume they're looking for inconsistency that could indicate a lack of conscientiousness.
At times when I have been anxious to get hired, I have had no problem demonstrating that I can fill out a bunch of redundant forms when required.
Sometimes you need to be able to do that sort of thing, even in the best organizations.
On the other hand, I don't think I'd intentionally add that to my hiring process.
There are better ways to check for conscientiousness than saying, "please do this redundant activity perfectly."
At times when I have been anxious to get hired, I have had no problem demonstrating that I can fill out a bunch of redundant forms when required.
Sometimes you need to be able to do that sort of thing, even in the best organizations.
On the other hand, I don't think I'd intentionally add that to my hiring process.
There are better ways to check for conscientiousness than saying, "please do this redundant activity perfectly."
I interviewed with a company a couple of months ago and it was the first time in my career that I'd had one of those technical interviews that folks here on HN seem to run into a lot. Was shown a handful of problems in a Google doc and told the code doesn't need to compile, it just needs to be conceptually sound. Got asked how to check if a word's a palindrome, how to check if delimiters are balanced, some basic data shaping with JSON, and a pretty basic SQL question with a left join.
I left the interview feeling totally confident I'd rocked it, since there were no "inverse binary tree" curveballs or anything like that, and figured that the company just wanted to make sure I knew what a stack was and what some properties of arrays are. Got rejected, asked for feedback and was told none would be given, so I rinsed the bad taste out of my mouth and went with another company instead.
I left the interview feeling totally confident I'd rocked it, since there were no "inverse binary tree" curveballs or anything like that, and figured that the company just wanted to make sure I knew what a stack was and what some properties of arrays are. Got rejected, asked for feedback and was told none would be given, so I rinsed the bad taste out of my mouth and went with another company instead.
Never expect feedback for why you were rejected. It is in the company's best interest not to explain to you why; any feedback could potentially expose them to legal liability.
This may be true, but in practice, it doesn't seem to happen. Aline Lerner (@leeny) wrote this blog post about this a while back:
https://blog.interviewing.io/no-engineer-has-ever-sued-a-com...
https://blog.interviewing.io/no-engineer-has-ever-sued-a-com...
It may be in the company's best interest to leave you in the dark, though frankly I question that wisdom and have never had it effectively defended by a knowledgeable party. And even if it is in their best interest? That doesn't mean you shouldn't expect professional courtesy out of an organization that disrupted your day and decided not to hire you after it.
Being decent to people is important and you are important enough that you can expect to be treated with decency.
Being decent to people is important and you are important enough that you can expect to be treated with decency.
I think it isn't about legality, its mostly that most people take rejection badly and get angry, and it isn't worth a recruiters time to deal with that nonsense.
That's an occupational hazard, one they accepted willingly when they started working as a recruiter. It's not my fault that they have to deal with bad apples.
In the meantime, a lot of us want to improve and be told what we did wrong. It's the least you can do if you used several days of the candidate's life, don't you think?
In the meantime, a lot of us want to improve and be told what we did wrong. It's the least you can do if you used several days of the candidate's life, don't you think?
yea i agree with you, its a crappy thing to do, I'm not justifying it, just saying what their thought process is.
I've conducted several engineer interviews and sometimes I find it just as nerve-racking as if I was interviewing myself, mostly because asking questions that give me "a lot of signal about the candidate’s skills while ensuring the candidate always feels comfortable and confident" can be pretty hard.
Can anyone share examples of the kinds of questions I should be asking? Are there any good articles about this?
Can anyone share examples of the kinds of questions I should be asking? Are there any good articles about this?
The way I structure my coding interviews is to have a simple first question that anyone should be able to solve, and then a follow-up "ok, let's now add this feature" question. I tell them upfront that googling is ok and give hints whenever I notice they are stuck. At the end of the first half, I ask if there's anything about their code that they'd like to change - basically a chance to code review. It tells me a lot about not just technical chops, but also awareness of what good practices are, as well as whether they are proactive and have an eye for quality.
The second half is the brownie points session: it's where the candidate gets a chance to demonstrate that they're better than average, be it by demonstrating strong algorithmic thinking, or good refactoring and/or testing practices or what have you. Good candidates ace questions on multiple dimensions and it's pretty easy to spot a gold nugget.
When the candidate doesn't meet the bar at this point, it becomes geared towards looking for growth potential (as far as me collecting signals go) and being an opportunity for learning for the candidate. It can be me giving feedback about types of things they could take into further consideration or, for less qualified candidates, a discussion of how to formulate an algorithmic idea, either in terms of thinking from first principles, or in terms of erasing dissonance between abstract ideas vs how to express them in code.
I try to always pace feedback in such a way that by the end of the hour, the candidate has completed the exercise. Sometimes, that does mean that I'm literally walking them through the process of coming up with the solution. Some think this is a waste of time, but IMHO, it's important for the candidate to leave with a good impression of the interview process. If a session is a complete bust and a waste of my time, then at the very least the candidate should be getting something out of it.
The second half is the brownie points session: it's where the candidate gets a chance to demonstrate that they're better than average, be it by demonstrating strong algorithmic thinking, or good refactoring and/or testing practices or what have you. Good candidates ace questions on multiple dimensions and it's pretty easy to spot a gold nugget.
When the candidate doesn't meet the bar at this point, it becomes geared towards looking for growth potential (as far as me collecting signals go) and being an opportunity for learning for the candidate. It can be me giving feedback about types of things they could take into further consideration or, for less qualified candidates, a discussion of how to formulate an algorithmic idea, either in terms of thinking from first principles, or in terms of erasing dissonance between abstract ideas vs how to express them in code.
I try to always pace feedback in such a way that by the end of the hour, the candidate has completed the exercise. Sometimes, that does mean that I'm literally walking them through the process of coming up with the solution. Some think this is a waste of time, but IMHO, it's important for the candidate to leave with a good impression of the interview process. If a session is a complete bust and a waste of my time, then at the very least the candidate should be getting something out of it.
My worst tech interview experience: all of them.
> Also, writing code on a whiteboard is fucking stupid — so there’s that.
Many places have switched to google docs now. Still just as stupid though.
> Also, writing code on a whiteboard is fucking stupid — so there’s that.
Many places have switched to google docs now. Still just as stupid though.
I love having informal meetings with recruiters, and half an hour later it turns out they are looking for java developers, not javascript.
>My worst tech interview experience: all of them.
Agreed. I thought it gets better. It doesn't. It gets way worse. Best jobs I interviewed for were around 2010 for jQuery and wordpress jobs.
>My worst tech interview experience: all of them.
Agreed. I thought it gets better. It doesn't. It gets way worse. Best jobs I interviewed for were around 2010 for jQuery and wordpress jobs.
I wonder if this works as a heuristic. It seems like companies working with mature software would have less pretense, and so feel less need to gatekeep. Working with stuff like PHP or classic libraries and frameworks might signal they recognize they're just tools to get a job done, and it doesn't matter how you go about it as long as it's on time, on budget, meets the spec, and won't get them sued.
to be fair, jQuery is pretty 'mature' at this point
That's the classic library I had in mind. I could have been clearer. It's not perfect, but it's as good as any library would be after 15 years of changes to meet new needs.
>Many places have switched to google docs now.
back then (~2004) for Google phone screen you had to "write", ie. to voice it, correct code over the phone - good luck if you didn't know that beforehand like me and was at the place without whiteboard nor pen&paper nor took laptop with you (i was just walking that Bay trail around Sun (nowdays FB) MPK campus), and i got the impression that they really expected you do to it from the mind ie. using say pen&paper would be cheating (i should have tried stick on the sand though :).
back then (~2004) for Google phone screen you had to "write", ie. to voice it, correct code over the phone - good luck if you didn't know that beforehand like me and was at the place without whiteboard nor pen&paper nor took laptop with you (i was just walking that Bay trail around Sun (nowdays FB) MPK campus), and i got the impression that they really expected you do to it from the mind ie. using say pen&paper would be cheating (i should have tried stick on the sand though :).
Even more stupid. "We'll 'let' you use a computer to do our totally contrived, useless code exercises, but you can't just share your screen and use an IDE so we can see how you actually. No, just use 2020's WordPad."
Seriously? Google docs are even worse than whiteboards.
At least Google Docs hast Syntax Highlighting ... Oh wait.
That would be funny if you solved their stupid question, then spent the rest of the time formating the doc to add syntax highlighting.
Interviewer: You can ask clarifying questions if you need to
You: What theme do you want me to use when I format this code? Monokai? Atom?
Interviewer: You can ask clarifying questions if you need to
You: What theme do you want me to use when I format this code? Monokai? Atom?
I don't love giving coding interviews, but we use CoderPad nowadays, which is pretty reasonable for this task, IMHO. Acceptable editor, you can run your code, etc. And as the interviewer, I can replay the session afterward if I want to retrace the path the candidate took.
Were your experiences at the jobs positive?
I think this shows how difficult interpretations can be. The interviewer was probably just kidding around, but given the stakes and the unfamiliar environment, it was probaboy a rough comment.
It's a good lesson in behavior. Even professional adults screw up and have foot-in-mouth moments.
It's a good lesson in behavior. Even professional adults screw up and have foot-in-mouth moments.
>I think this shows how difficult interpretations can be
It's not interpretation, really, I think. It speaks to the asymmetry of the situation and how, if you are the interviewer, you need to be thoughtful about what you say at all.
I learned this early on, much to my chagrin. An interviewee was obviously stuck and getting themselves in a muddle so I stopped them and redirected to a different question; I thought it was in a lighthearted manner and communicated that I wanted them to relax and regroup - found out later they felt I was making fun of them and had a terrible interview experience. Ever since then I've been much more careful and explicit.
What I thought was being considerate was read as being condescending, I suspect, even though my intent was pure the situation is fraught with potential for miscommunication.
It's not interpretation, really, I think. It speaks to the asymmetry of the situation and how, if you are the interviewer, you need to be thoughtful about what you say at all.
I learned this early on, much to my chagrin. An interviewee was obviously stuck and getting themselves in a muddle so I stopped them and redirected to a different question; I thought it was in a lighthearted manner and communicated that I wanted them to relax and regroup - found out later they felt I was making fun of them and had a terrible interview experience. Ever since then I've been much more careful and explicit.
What I thought was being considerate was read as being condescending, I suspect, even though my intent was pure the situation is fraught with potential for miscommunication.
It's difficult to know how best to react to interviewees being stuck. If you leave them stuck, they may take it badly; if you redirect them, they may take it as a sign that they "failed" this part of the interview.
I try to say something along the lines of "OK, I think it's time to move on to something else; in an interview situation, you sometimes go down a blind alley, but that does not really reflect on the real world, and I think I've seen enough to move on to the next subject."
I try to say something along the lines of "OK, I think it's time to move on to something else; in an interview situation, you sometimes go down a blind alley, but that does not really reflect on the real world, and I think I've seen enough to move on to the next subject."
The latter is similar to the approach I take also - but tellingly also what I thought I was saying in the situation related about. I'm more careful with language now.
Yes, and even if it _was_ in fact what you were saying, it may not have been the message that got through to them.
I have to agree, I would guess that the interviewer could tell the OP was nervous and was trying to lighten the mood a bit. Though, asking someone to write a language they don't use everyday is a pretty horrific thing to do in an interview. I've always been able to interview in my preferred language, even if the company didn't have one line of it in production.
Kidding around is kinda risky- it can easily come off as not taking you or your time seriously.
Treat people with respect seems to be uncommon common sense.
Treat people with respect seems to be uncommon common sense.
[deleted]
Somewhat tangential (for the possible future): out of blue my paypal account was suspended recently, permanently, and they refuse to give any reason. Now I'm thinking to apply for some positions there only to raise this topic with the hiring manager :)
Similar boat here. If you get an interview let me know so you can check mine too :)
Had an interviewer literally laugh in my face at an answer I gave once and exclaim "Oh my god!". Never forgot that.
That sounds like a wildly inappropriate response, but mind telling us more?
Sure. I guess I won't name names, but it happened something like ten years ago. It was for a pretty large online stock trading platform. It was a previous era of my career when I was a full stack web dev. The interview question involved some kind of CSS gotcha. I couldn't figure it out and asked if I could Google it. The interviewers agreed. I pulled up some search results and started looking past the first few because they looked kinda click baity. One of the interviewers said something like, "Whoa, back up and look at the first link. That guy knows what he's talking about; he's the man." So I clicked on it and took a look. But by that time I was pretty nervous and my brain just wasn't working. I looked over the article and couldn't make sense of it quickly enough to figure out the answer. I think I told the interviewers something to that effect. That's when one of them laughed out loud and said, "Oh my god! It's right there in front of you!" I didn't get the job of course.
That situation has replayed a lot of times in my head since then. It was one of those things where I wish I could have done something glorious and snarky to put the guy in his place. Probably best that I didn't do that though. I think reacting defensively like that just incurs an emotional cost.
That situation has replayed a lot of times in my head since then. It was one of those things where I wish I could have done something glorious and snarky to put the guy in his place. Probably best that I didn't do that though. I think reacting defensively like that just incurs an emotional cost.
> I didn't get the job of course
Congratulations.
Congratulations.
Those are exactly the kind of assholes that should be named.
So... how is that "worst" interview experience? You probably haven't seen really bad interviews.
My favourite was switching conference rooms until we ran out of time and the interviewer thanked me and invited for a next session. There was also one when the guy was late 30 minutes to a 30 minute interview. And the one when they spent 1h with me and at the end told me the position has already been taken. I had one where interviewer smelled really, really bad -- I left when I learned he would be my boss.
I also had one where the guy said he is "best programmer in the world". I thought he is joking. Unfortunately, he wasn't. He became my boss. I left a month later when his code failed in prod (he parsed XML by specifying a line and character number to extract piece of data) but he blamed it first on the vendor (they apparently changed the format when they turned off pretty printing) and then on me (I haven't even touched the code). Apparently he never makes mistakes -- he always blames somebody else.
To be fair, I have also a lot of "bad candidate" stories. Like a guy with a lot of knowledge who says at the end of interview he doesn't want to get hired, he just came to exercise before going to another company.
From my PoV as interviewer I think the only real egregious error here asking the candidate to write in unfamiliar language. It doesn't matter what the language the project uses, the whiteboard needs to use language that is comfortable for the candidate. We can discuss knowledge of the language as a separate issue.
Now, asking the candidate to write a particular algorithm on a whiteboard from memory is just a waste of time. The purpose of programming exercise is to see if the person knows how to program, not if they have memorised particular algorithm.
Writing an algorithm like merge sort could still be productive if the interviewer has first explained the algorithm and then asked to implement it.
But I still feel merge sort is a bad choice -- I prefer simple task but one that I created myself so no candidate is familiar with it. I am interested how the candidate works on the task and how he can communicate with me to solve it. You would be surprised how many candidates dismiss hints they are being offered.
My favourite was switching conference rooms until we ran out of time and the interviewer thanked me and invited for a next session. There was also one when the guy was late 30 minutes to a 30 minute interview. And the one when they spent 1h with me and at the end told me the position has already been taken. I had one where interviewer smelled really, really bad -- I left when I learned he would be my boss.
I also had one where the guy said he is "best programmer in the world". I thought he is joking. Unfortunately, he wasn't. He became my boss. I left a month later when his code failed in prod (he parsed XML by specifying a line and character number to extract piece of data) but he blamed it first on the vendor (they apparently changed the format when they turned off pretty printing) and then on me (I haven't even touched the code). Apparently he never makes mistakes -- he always blames somebody else.
To be fair, I have also a lot of "bad candidate" stories. Like a guy with a lot of knowledge who says at the end of interview he doesn't want to get hired, he just came to exercise before going to another company.
From my PoV as interviewer I think the only real egregious error here asking the candidate to write in unfamiliar language. It doesn't matter what the language the project uses, the whiteboard needs to use language that is comfortable for the candidate. We can discuss knowledge of the language as a separate issue.
Now, asking the candidate to write a particular algorithm on a whiteboard from memory is just a waste of time. The purpose of programming exercise is to see if the person knows how to program, not if they have memorised particular algorithm.
Writing an algorithm like merge sort could still be productive if the interviewer has first explained the algorithm and then asked to implement it.
But I still feel merge sort is a bad choice -- I prefer simple task but one that I created myself so no candidate is familiar with it. I am interested how the candidate works on the task and how he can communicate with me to solve it. You would be surprised how many candidates dismiss hints they are being offered.
Netflix should green light a series on bad tech interviews. With Zoom and screen recording there’s an easy way to gain raw materials. And then once we name, shame, and normalize that this is nuts, we can move on.
FWIW I don’t think Apple has a standardized interview process. Unlike companies like google or FB, each individual team decides its own interview questions.
That means it’s possible to have a horrible interview experience with one team, and a great experience with another team.
Not saying this system is good or bad, just trying to describe the system.
That means it’s possible to have a horrible interview experience with one team, and a great experience with another team.
Not saying this system is good or bad, just trying to describe the system.
This is correct, and the hiring process is broken at Apple in myriad ways, some of which you would not imagine would be allowed, let alone encouraged.
A recent interview experience that stuck with me was being told at the end of it that I obviously know my stuff but I just need more interview experience...
my worst tech interview: i was asked to solve a leetcode problem on a google doc.
i asked if i could at least do on my editor of choice while screensharing -- "nope, too complicated".
i asked if i could do in pseudocode, nope "it must at least run".
i tried for 10min, said "thank you, but i don't think this is working for us -- we can probably stop here. thank you for your time [yadda yadda]".
i asked if i could at least do on my editor of choice while screensharing -- "nope, too complicated".
i asked if i could do in pseudocode, nope "it must at least run".
i tried for 10min, said "thank you, but i don't think this is working for us -- we can probably stop here. thank you for your time [yadda yadda]".
Good for you. The days when we where expected to right code without a computer ended quite some time ago. It takes a lot of strength, intellignence and maturity for the candidate to terminate the process and I respect that from both sides of the table.
you know, i quite liked the position, but i was always told that "interviews are two way streets". if that's how they interview their candidates... well, let's say i don't want to work with people that were hired with that process.
the good thing is that i interviewed and was hired about three weeks later -- and it was an even better position!
the good thing is that i interviewed and was hired about three weeks later -- and it was an even better position!
As someone who is in their final week at Facebook, I'd be keen to read why he felt joining was a big mistake. I have a similar feeling myself -- on paper it was a great job but I was miserable.
I haven't read any positive opinion of people that was working for big companies so far to be honest.
We all know that companies use Leetcode problems for programming questions. But Facebook (and perhaps other big tech companies) also like to ask "system design and architecture" questions, which in my personal opinion don't have anything to do with the real world system design and architecture. Those questions are geared at recent college graduates who have no experience in system design. But if you've designed and created actual successful systems, you're likely to fail such questions. Because when you have real experience, you tend to know what works and what doesn't work in the real world, and you are likely to be conservative in the choice of your design techniques. However the interviewer expects you to use all kinds of design techniques which look good on the whiteboard but usually fail. I didn't realize how bad this situation was until I came across some books explaining how to "pass" these system design questions: you're basically supposed to say a load of bullshit, the more bullshit the better. I think the disconnect between the interview questions and the actual professional experience is simply stunning.
> I had to deal with an asshole making jokes
My read is that the primary cause of the bad experience is because of a perception that the interviewer made a joke about missing semicolon in the white board code.
The attribution of that being “asshole” seems typical for a young guy who was stressed in a technical interview. Especially there could be additional signaling in the interview process that is problematic to the interviewee.
But the whole post does not sound too bad to me.
My personal worst example is one guy who is asking what I did previously, and after each time I gave an overview of one project, that guy just said: that sounds very easy (that was in Chinese, we were doing the interview in Chinese over phone). And that guy is a msft researcher turned engineer. I was internally amused at his employer being clueless about the skill gaps between an engineer and a researcher.
To me the saddest part was that he basically is not able to present an interesting description of the prospect projects in his own team (apparently that's expected based on his reactions to my previous projects), nor appreciate my side of the story. That makes the time spent close to being meaningless for both of us.
My read is that the primary cause of the bad experience is because of a perception that the interviewer made a joke about missing semicolon in the white board code.
The attribution of that being “asshole” seems typical for a young guy who was stressed in a technical interview. Especially there could be additional signaling in the interview process that is problematic to the interviewee.
But the whole post does not sound too bad to me.
My personal worst example is one guy who is asking what I did previously, and after each time I gave an overview of one project, that guy just said: that sounds very easy (that was in Chinese, we were doing the interview in Chinese over phone). And that guy is a msft researcher turned engineer. I was internally amused at his employer being clueless about the skill gaps between an engineer and a researcher.
To me the saddest part was that he basically is not able to present an interesting description of the prospect projects in his own team (apparently that's expected based on his reactions to my previous projects), nor appreciate my side of the story. That makes the time spent close to being meaningless for both of us.
I mean I don't know. A joke which may have been intended to give a hint, while putting applicant at ease, has clearly backfired ; but if that's the worst interview they have had, they're pretty lucky.
I also notice the paragraph near the end with couple of general lines on good interview and the "that's how I hold interviews".
Here's the thing. Nobody sets off to intentionally be a bad interviewer or coder or manager or whatever. It helps to have humility and significant open introspection to be good at something (not the only path but for most of us it's the best path). We ascribe wilful incompetence to others while we have excuses and lessons learned for ourselves. Maybe - likely - the other interviewer too thought they were giving opportunities and signals and letting people at ease?
I also notice the paragraph near the end with couple of general lines on good interview and the "that's how I hold interviews".
Here's the thing. Nobody sets off to intentionally be a bad interviewer or coder or manager or whatever. It helps to have humility and significant open introspection to be good at something (not the only path but for most of us it's the best path). We ascribe wilful incompetence to others while we have excuses and lessons learned for ourselves. Maybe - likely - the other interviewer too thought they were giving opportunities and signals and letting people at ease?
This is a great example of intent vs. impact. Regardless of the intent, the impact was negative. Recognizing how their actions impact the candidate is a huge part of interviewing, and the interviewer should have seen the candidate get nervous and adjusted.
That said, given that candidates are generally nervous to some extent anyway, and semi-colons shouldn't matter in a whiteboard interview, that joke seemed like in poor taste to me. That underscores why we need better training and mentorship for interviewers.
That said, given that candidates are generally nervous to some extent anyway, and semi-colons shouldn't matter in a whiteboard interview, that joke seemed like in poor taste to me. That underscores why we need better training and mentorship for interviewers.
Years ago when I first graduated went to an interview for a Java dev role. Spent the full day there getting pulled apart by whiteboard interviews, exam papers, and daft questions that would have no real day-to-day use in a dev role. Even worse was I asked at the end of the day what kind of work I could be expected to do and found out there was very little actual dev work; maybe some maintenance tasks but mostly support. I became pretty bitter about tech interviews after that.
Sadly interviews like that became a regular fixture and some were even worse. In a few I even had take-home assignments where I was to implement a full-project from scratch then present it at the interview (as well as all that other crummy interview stuff). I even got heavily criticised/insulted in one for prioritising my current job over the assignment and was told if I really wanted the position I "should've moved heaven and earth" - pretty deranged to ask someone to risk their income for an unpaid assignment if you ask me but anyways.
With that being said, I do think interviews are becoming better. They're less about blowing smoke up the interviewers arse and more about judging how good a fit they are for the company. Interviews tend to feel more collaborative and white-boarding sessions aren't a test but a discussion, with the best language agnostic. Hopefully they keep going this way.
Sadly interviews like that became a regular fixture and some were even worse. In a few I even had take-home assignments where I was to implement a full-project from scratch then present it at the interview (as well as all that other crummy interview stuff). I even got heavily criticised/insulted in one for prioritising my current job over the assignment and was told if I really wanted the position I "should've moved heaven and earth" - pretty deranged to ask someone to risk their income for an unpaid assignment if you ask me but anyways.
With that being said, I do think interviews are becoming better. They're less about blowing smoke up the interviewers arse and more about judging how good a fit they are for the company. Interviews tend to feel more collaborative and white-boarding sessions aren't a test but a discussion, with the best language agnostic. Hopefully they keep going this way.
I had the same experience with Apple about a year ago. Not merge sort, but an algorithm question that also involved a fair bit of math. The type where if you know the number theory trick, the implementation becomes straightforward, but if you don't, the solution is obviously suboptimal.
The recruiter also pushed me to interview with other teams, but I quickly said "no, thanks". I can't necessarily say I was frustrated though — this experience is more or less exactly what I expected from Apple or any FAANG.
The recruiter also pushed me to interview with other teams, but I quickly said "no, thanks". I can't necessarily say I was frustrated though — this experience is more or less exactly what I expected from Apple or any FAANG.
Interesting. What was the number theory trick? I like these sorts of problems.
If the role required some math along with software engineering, then it could have been a question that provided a good signal.
If the role required some math along with software engineering, then it could have been a question that provided a good signal.
I was expecting a horror story about some leet code problem. It's been 5 years since I last interviewed, but I always memorized how to write the common sort algorithms ahead of time first. Having to write merge sort in C doesn't really feel like a big ask. I don't know, maybe I'm old fashioned. Even if we pretend people don't spend months training on leetcode before interviews nowadays, surely sorting algorithms are still taught in basic data structures classes, right?
Not everyone became a developer through CS classes. I'm self-learned, mostly learned what I needed at the job to do that job. I don't think in 10 years I've ever needed to write a sorting algorithm since, well, that's built into the language, so why would I? I've had many jobs, learned many programming languages, and haven't seen one without a sort functionality built-in, or for trickier things where a more advanced library would not be available.
Now maybe this is the whole point, to filter out those who never went to university, but I'd say it's still pretty dumb to test people on things that most likely have nothing to do with the job or just aren't realistic.
Now maybe this is the whole point, to filter out those who never went to university, but I'd say it's still pretty dumb to test people on things that most likely have nothing to do with the job or just aren't realistic.
That seems like a really inefficient way to filter out people who don't have a CS degree, given that you enter your degree info on the app (and they background check all hires). I agree with you though, I don't understand why the leetcode style interviews are so damn pervasive.
They almost never ask a question you are familiar with, and recently implemented, that's the problem.
"Oh, I know that one!" is not a solution for the rest of us. Including you at the next interview where the different question is to implement the Ceph distributed filesystem on a whiteboard, clock-ticking, and an asshole looking over your shoulder.
"Oh, I know that one!" is not a solution for the rest of us. Including you at the next interview where the different question is to implement the Ceph distributed filesystem on a whiteboard, clock-ticking, and an asshole looking over your shoulder.
Never in my life have a coded on a whiteboard, so why on earth would I need to write compilable code on one to prove that I can write in an IDE or solve problems? It just doesn't make any sense; it's like asking a writer prove that they can set type in a Gutenberg press—why!? Sure, I can understand writing high level pseudocode on a whiteboard, but getting hung up on something like semicolons is literally pedantic and a power trip on the interviewer's side.
Also, when I was younger I was diagnosed with a condition called dysgraphia where my handwriting is terrible, which is why I got into typing when I was young and eventually programming. So writing legibly on a whiteboard is just an awful prospect for me as I need to think about how to write something just as much as what I'm writing.
I don't think writing a merge sort is either a trick question or an esoteric puzzle. Neither is using a whiteboard during a tech interview. It's very common. I'm sorry this author had a bad experience with it.
For me, it's all about mindset. Interviews are a two way street. Talk to the interviewer, they're people too. If there are assholes, then whatever, you've still learned more and gotten to an better outcome for you.
If you don't know the language you're asked to write something in, ask to change it to something you do know. If the interviewer says language X is required for the job just be upfront about it. Stop the interview right there and address that issue. 'Look, I don't know/haven't used x in a while. Can I use y with the understanding that I need to come up to speed quickly? Otherwise, we can get our days back.'
The shame here is that the author is still clearly bitter about something that happened 6 years ago and the interviewer probably chalked it up to another hack who can't even implement a merge sort.
For me, it's all about mindset. Interviews are a two way street. Talk to the interviewer, they're people too. If there are assholes, then whatever, you've still learned more and gotten to an better outcome for you.
If you don't know the language you're asked to write something in, ask to change it to something you do know. If the interviewer says language X is required for the job just be upfront about it. Stop the interview right there and address that issue. 'Look, I don't know/haven't used x in a while. Can I use y with the understanding that I need to come up to speed quickly? Otherwise, we can get our days back.'
The shame here is that the author is still clearly bitter about something that happened 6 years ago and the interviewer probably chalked it up to another hack who can't even implement a merge sort.
I'd love if OP had more details on how they ask "great questions that give her a lot of signal about the candidate’s skills while ensuring the candidate always feels comfortable and confident". I hate passing interviews and as a result try my best to be a chill interviewer, but I yet have to find good conversational questions that get me confidence in ones' coding abilities.
Backblaze asked me to implement a HashMap for a senior dev position, lol. The company is actively selecting for new-grads for senior positions.
[deleted]
Back in 1994, was interviewing with Some Big Finance (SBF) wall street firm in NYC. They wanted to pair me with one of their traders to write code in real-time for intraday trades. Interviewer asked me to whiteboard a String implementation in C++. Grabbed the marker and wrote on the whiteboard:
typedef RWCString SBFString;
My best interview experiences were light on the technical questions are mostly back-and-forth discussion around my experience/tech.
He took great offense at the semicolon comment, but I'm not convinced it was meant to be snide. Kinda sounds like the interviewer with just pointing out the semicolons in a roundabout way.
But I supposed another lesson for interviewers is to be aware of how stressful interviews are for the candidate, and to mind their language and jokes.
But I supposed another lesson for interviewers is to be aware of how stressful interviews are for the candidate, and to mind their language and jokes.
That may be true, but in situations with significant power imbalance it's important for the person in the position of power to recognize it and to not wield it inappropriately. A joke like that when somebody is under interview stress has the possibility (not the guarantee, but the possibility) of harming the interviewee's chances by nudging them in the wrong way at the wrong time in a tough situation, and that's pretty lousy to do to somebody.
My worst interview was for chief technical architect for a small software house.
I was asked to write a parser which could transform a simple data format into another.
I asked whether they were looking for a fast solution, or a better one? I was told it had to be fast and better.
Thinking I hadn't explained myself very well, I asked again, are you measuring how fast I can give you a solution, or are you looking for quality. I could do either. Again, I was told it had to be high quality and fast to produce.
I took the middle ground, and wrote something in a couple of hours that did everything they wanted, and was extensible to new formats, using a variety of OO techniques.
I failed the test because I hadn't used a standard library component that could be coaxed into doing that they wanted. I clearly didn't grasp the awesome power and reusability of object orientation!
I was asked to write a parser which could transform a simple data format into another.
I asked whether they were looking for a fast solution, or a better one? I was told it had to be fast and better.
Thinking I hadn't explained myself very well, I asked again, are you measuring how fast I can give you a solution, or are you looking for quality. I could do either. Again, I was told it had to be high quality and fast to produce.
I took the middle ground, and wrote something in a couple of hours that did everything they wanted, and was extensible to new formats, using a variety of OO techniques.
I failed the test because I hadn't used a standard library component that could be coaxed into doing that they wanted. I clearly didn't grasp the awesome power and reusability of object orientation!
I think a fun/useful question would be along the lines of tell me one of the biggest mistakes you’ve made in X language that shows up quite a bit on the resume.
I'm not so sure. I just simulated that question in my head with C# and I can't think of a single interesting answer despite 3 years of using it.
I dislike these questions. Not everyone compartmentalizes their experiences using technology into "best," "worst," "biggest," etc. I have 26 years of software development experience. At this point, it's all feel, intuition, and instinct.
as a senior IC, I've been asked to give technical peer interviews for candidates quite a few times.
A LOT of the places I have worked there's no budget for sensible interview tools even for remote interviews (shared IDEs, etc), so you are stuck with what you can cobble together (an ad hoc shared REPL, a shared virtual whiteboard, etc). They suck a lot, and I try to keep that in account when working through problems.
The best experiences are always in an actual simple dev environment where you can collaborate on code, have a live preview of UI stuff, allow access to stack overflow and other references, etc. it allows you to present a problem very similar to day-to-day work but smaller scale.
And I gotta say, even that is just somewhat useful for gauging how working with that person for real would be. Interviews suck - nerves are frayed, it's not always representative of that persons skill, ability or non-assholishness, AND it doesn't allow for assessing general skill, ability to learn or ramp up, because everyone necessarily in the interview has to have some skill in the language and platform you are working in during the interview.
A LOT of the places I have worked there's no budget for sensible interview tools even for remote interviews (shared IDEs, etc), so you are stuck with what you can cobble together (an ad hoc shared REPL, a shared virtual whiteboard, etc). They suck a lot, and I try to keep that in account when working through problems.
The best experiences are always in an actual simple dev environment where you can collaborate on code, have a live preview of UI stuff, allow access to stack overflow and other references, etc. it allows you to present a problem very similar to day-to-day work but smaller scale.
And I gotta say, even that is just somewhat useful for gauging how working with that person for real would be. Interviews suck - nerves are frayed, it's not always representative of that persons skill, ability or non-assholishness, AND it doesn't allow for assessing general skill, ability to learn or ramp up, because everyone necessarily in the interview has to have some skill in the language and platform you are working in during the interview.
Not from an interview, but I once took a small contract for some kind of data processing work. The guy who hired me was insisting that HTTP was an asynchronous protocol. I corrected him, thinking "oh, it's no big deal, he might've just misspoke," but the guy became absolutely irate. Hey buddy, not my fault you've never read the RFC.
Apply Hanlon's Razor to that comment
Sadly, hundreds of comments that would appear to prove that "experience" is of absolutely no value in candidates. Rather companies just apparently look for quick-thinking, smart people that can answer recently memorized text-book questions.
They should have probably applied these tips: https://talktotheduck.dev/debugging-the-technical-interview-...
There is exactly one position for which asking or commenting on semicolon use in an interview is a good use of time. If the position being interviewed for is to write the semicolon insertion pass in a JavaScript parser.
I once interviewed for a company in Austin. I was kept in a small room with no ventilation for five hours. No breaks, no water offered. They got upset at me because I said I didn't like JavaScript.
Funny times.
Funny times.
[deleted]
> I didn’t write any of those sorting algorithms from memory. I referenced the infinite number of resources on the Internet to write them and ensure they were correct.
I don't think the idea is to have a merge sort committed to memory. More like one can go from specification to implementation in a reasonable amount of time. Me, I kinda like to write my own first, then compare it with others.
Getting flustered when on the stage is a real problem, but it fades away as one gets experienced at being on stage. Then you can respond to snarky comments with a bit of snark of your own.
I don't think the idea is to have a merge sort committed to memory. More like one can go from specification to implementation in a reasonable amount of time. Me, I kinda like to write my own first, then compare it with others.
Getting flustered when on the stage is a real problem, but it fades away as one gets experienced at being on stage. Then you can respond to snarky comments with a bit of snark of your own.
I would love it if, at some point, the interviewers go for a job, and they get told to implement a merge sort in C on a whiteboard.
I think merge sort is actually pretty intuitive, why not go for the gold with quicksort?
Quicksort is actually possible; it's really simple.
What really would tick the box is Timsort: https://en.wikipedia.org/wiki/Timsort
What really would tick the box is Timsort: https://en.wikipedia.org/wiki/Timsort
Mergesort and quicksort both work on the principle of sorting both halves of a list separately and then combining them. But mergesort is much simpler than quicksort.
Mergesort makes dividing the list in half easy: you just cleave the list at the halfway point. Then it's your job to assemble two small sorted lists into one big sorted list, which is also easy.
Quicksort makes assembling the large list easy: everything in the left list is smaller than everything in the right list, so all you need to do is concatenate the two sublists. But we've made something that was already easy even easier at the cost of making dividing the list much more difficult. Now instead of cutting the list in half, we have to rearrange it into a small part on the left and a large part on the right.
(Actually, you can just assemble new lists by filtering the input for small numbers (and passing them to the left) and then refiltering for large numbers (and passing them to the right). You're already doing O(n) work on the input, so doing O(n) work two more times won't change the asymptotic complexity. But anyone who's looking for an elegant solution will hate you.)
Mergesort makes dividing the list in half easy: you just cleave the list at the halfway point. Then it's your job to assemble two small sorted lists into one big sorted list, which is also easy.
Quicksort makes assembling the large list easy: everything in the left list is smaller than everything in the right list, so all you need to do is concatenate the two sublists. But we've made something that was already easy even easier at the cost of making dividing the list much more difficult. Now instead of cutting the list in half, we have to rearrange it into a small part on the left and a large part on the right.
(Actually, you can just assemble new lists by filtering the input for small numbers (and passing them to the left) and then refiltering for large numbers (and passing them to the right). You're already doing O(n) work on the input, so doing O(n) work two more times won't change the asymptotic complexity. But anyone who's looking for an elegant solution will hate you.)
yes, if u don't remember it, it takes a big of thought to how to use two pointers to sort left and right for quicksort
read the rest of the website too, its really funny. what a character Jesse is!
A lot of people are really not good at conducting interviews. It's a hard skill, it has absolutely nothing to do with the rest of your job, nobody teaches you how to do it well, nobody checks to see if you're doing it well, and there's no good resources for learning. You get like a couple hours of "interview training" (50% of which is "here's how to not get us sued 101"), maybe some shadow interviews if you're lucky, and then they just throw you in the deep end and never check back.
Whiteboard interviews do suck, but they exist because nobody's figured out a better alternative that works at scale. If you're a small company, you can get away with a less sucky interviewing method. If you're a massively large company, a lot of those fall apart because of various reasons (you can't ask for take-home tests because a significant percentage of your applicant pool will refuse to do it because they already have a job and stuff to do at home, you can't ask to "talk about interesting code/projects you've worked on", because either (a) they already have a job but can't show you any code because it's owned by another company, or (b) they just outright lie about everything and you don't figure it out for 6 months, etc etc).
So whiteboard interviews suck, but we're stuck with them.
There's some really weird things about conducting a good whiteboard interview which are not obvious
1. The candidate should not know if they're failing. The candidate should basically always get the sense that they're doing okay enough, even if they aren't. If the candidate fails your interview, but aces all the others, that's fine. Probably they should still get hired. But if the candidate fails your interview and feels really badly about having bombed it, then they just go on tilt and fail the rest anyways. That's not good signal, it wastes the candidate's time, it wastes the rest of the interviewers' time, all because you the earlier interviewer couldn't figure out how to not tilt the candidate. This is less important if you're the last interviewer on a loop. - so generally you want to start out easy, be really encouraging, and ramp up difficulty as they go on.
Tilt is real, and it is not helpful in an interview situation.
(Caveat to #1 - this is assuming you're working at a big enough company where your policy is to give zero actionable feedback to the candidate due to lawsuits, which is probably any large company. If you're not at a large enough company where this is true, why are you even doing whiteboard interviewing? Stop lol, whiteboard interviewing sucks)
2. You can't ask anything crazy domain specific. Sure maybe the specific super detailed queuing problem you're working on right now is fun, but it probably doesn't scale well to arbitrary-engineer who hasn't thought about queuing for a decade. Unfortunately this means you have to spend a lot of time figuring out what to ask, because the things you're currently working on are almost certainly terrible interview questions.
Corollary to #2 - if you pick questions from online, or even from within your company, candidates will absolutely have seen them before, memorized them, and go from there. Your question needs to be able to be modified, expanded, and you need to know what it
3. Benefit of doubt should always go to the candidate. Forgot a library? You tell them the library, and don't count it against them. You are the candidate's StackOverflow for the interview, be reasonable.
#1 up there is the hardest. Even simple things become very difficult to broach. If the candidate is digging themselves in a hole and you are having a hard time figuring out how to hint them out without psyching them out, feign ignorance about your own interview question and try to "collaboratively" work your way out of it.
Sometimes it's impossible. Sometimes you'll get a candidate who literally does not know even the most basic of programming stuff for their own chosen programming language (obviously has not ever written code at all). I don't actually know how to handle that. Sometimes the recruiters will make mistakes and just send you candidates for the wrong job. So this isn't all-encompassing advice, because there's always edge cases.
Whiteboard interviews do suck, but they exist because nobody's figured out a better alternative that works at scale. If you're a small company, you can get away with a less sucky interviewing method. If you're a massively large company, a lot of those fall apart because of various reasons (you can't ask for take-home tests because a significant percentage of your applicant pool will refuse to do it because they already have a job and stuff to do at home, you can't ask to "talk about interesting code/projects you've worked on", because either (a) they already have a job but can't show you any code because it's owned by another company, or (b) they just outright lie about everything and you don't figure it out for 6 months, etc etc).
So whiteboard interviews suck, but we're stuck with them.
There's some really weird things about conducting a good whiteboard interview which are not obvious
1. The candidate should not know if they're failing. The candidate should basically always get the sense that they're doing okay enough, even if they aren't. If the candidate fails your interview, but aces all the others, that's fine. Probably they should still get hired. But if the candidate fails your interview and feels really badly about having bombed it, then they just go on tilt and fail the rest anyways. That's not good signal, it wastes the candidate's time, it wastes the rest of the interviewers' time, all because you the earlier interviewer couldn't figure out how to not tilt the candidate. This is less important if you're the last interviewer on a loop. - so generally you want to start out easy, be really encouraging, and ramp up difficulty as they go on.
Tilt is real, and it is not helpful in an interview situation.
(Caveat to #1 - this is assuming you're working at a big enough company where your policy is to give zero actionable feedback to the candidate due to lawsuits, which is probably any large company. If you're not at a large enough company where this is true, why are you even doing whiteboard interviewing? Stop lol, whiteboard interviewing sucks)
2. You can't ask anything crazy domain specific. Sure maybe the specific super detailed queuing problem you're working on right now is fun, but it probably doesn't scale well to arbitrary-engineer who hasn't thought about queuing for a decade. Unfortunately this means you have to spend a lot of time figuring out what to ask, because the things you're currently working on are almost certainly terrible interview questions.
Corollary to #2 - if you pick questions from online, or even from within your company, candidates will absolutely have seen them before, memorized them, and go from there. Your question needs to be able to be modified, expanded, and you need to know what it
3. Benefit of doubt should always go to the candidate. Forgot a library? You tell them the library, and don't count it against them. You are the candidate's StackOverflow for the interview, be reasonable.
#1 up there is the hardest. Even simple things become very difficult to broach. If the candidate is digging themselves in a hole and you are having a hard time figuring out how to hint them out without psyching them out, feign ignorance about your own interview question and try to "collaboratively" work your way out of it.
Sometimes it's impossible. Sometimes you'll get a candidate who literally does not know even the most basic of programming stuff for their own chosen programming language (obviously has not ever written code at all). I don't actually know how to handle that. Sometimes the recruiters will make mistakes and just send you candidates for the wrong job. So this isn't all-encompassing advice, because there's always edge cases.
[deleted]
Nowadays, with 20+ years of experience as a software developer behind me, having worked for Apple, First American, Bloomberg, AT&T, Booking, Amazon, many startups, etc. my job interviews have never been easier.
Before I am presented with a dumbass interviewer who throws a ridiculous question my way about algorithmic stuff, I prepare them: "Since we are both seeing if the other party is competent, I want you to know that I want you to also solve my questions. They will be slightly more difficult than the questions you pose to me."
When I applied for a job at Toptal this made the algorithm-test disappear like snow before an up-close nuclear blast.
I've interviewed hundreds of candidates over the years and I would never ask a question I can't also answer from the top of my head, in detail, and then some. Turns out, most technical interviewers who ask you "write a bubble sort" couldn't do it themselves.
And if they could, it'd be full of bugs. I mean, I'd rather have developers on my team who Google "bubble sort python" and go for a tried and tested open-source solution. I don't need developers who can reinvent complicated wheels from scratch; I want developers who are efficient.
Likewise, I don't want to work for a company where developers pride themselves on over-engineering their things.
Having worked at Apple, it doesn't surprise me one bit how slow they are developing simple features and fixing simple bugs. It's a red-tape hell full of not-very pragmatic engineers that are way too smart for the good of the company.
Before I am presented with a dumbass interviewer who throws a ridiculous question my way about algorithmic stuff, I prepare them: "Since we are both seeing if the other party is competent, I want you to know that I want you to also solve my questions. They will be slightly more difficult than the questions you pose to me."
When I applied for a job at Toptal this made the algorithm-test disappear like snow before an up-close nuclear blast.
I've interviewed hundreds of candidates over the years and I would never ask a question I can't also answer from the top of my head, in detail, and then some. Turns out, most technical interviewers who ask you "write a bubble sort" couldn't do it themselves.
And if they could, it'd be full of bugs. I mean, I'd rather have developers on my team who Google "bubble sort python" and go for a tried and tested open-source solution. I don't need developers who can reinvent complicated wheels from scratch; I want developers who are efficient.
Likewise, I don't want to work for a company where developers pride themselves on over-engineering their things.
Having worked at Apple, it doesn't surprise me one bit how slow they are developing simple features and fixing simple bugs. It's a red-tape hell full of not-very pragmatic engineers that are way too smart for the good of the company.
> Before I am presented with a dumbass interviewer who throws a ridiculous question my way about algorithmic stuff, I prepare them: "Since we are both seeing if the other party is competent, I want you to know that I want you to also solve my questions. They will be slightly more difficult than the questions you pose to me."
This is a great way to end the entire job interview process and make sure you're never called back again.
Seriously though, I hope everyone reading this recognizes how ridiculous it is. If you go into interviews thinking you can neg your interviewer, refuse parts of the interview, and they're going to love it so much that they'll offer you a job, you're mistaken.
This is a great way to end the entire job interview process and make sure you're never called back again.
Seriously though, I hope everyone reading this recognizes how ridiculous it is. If you go into interviews thinking you can neg your interviewer, refuse parts of the interview, and they're going to love it so much that they'll offer you a job, you're mistaken.
> Seriously though, I hope everyone reading this recognizes how ridiculous it is. If you go into interviews thinking you can neg your interviewer, refuse parts of the interview, and they're going to love it so much that they'll offer you a job, you're mistaken.
I once flat out refused to solve a question and still got an offer.. It really depends on a lot of variables to make a blanket statement either way. One of the variables is your level of experience. After a point, the fact that the interview goes both ways can skew heavily in favor of the candidate and if you're tactful and polite you can totally get away with driving the interview away from stupid problems. If you can't, then maybe you don't belong there and maybe that's ok. It's a win-win. A job is not a blessing, it's just a job. Unless you're starving, there's no point in pretending you're drone.
I once flat out refused to solve a question and still got an offer.. It really depends on a lot of variables to make a blanket statement either way. One of the variables is your level of experience. After a point, the fact that the interview goes both ways can skew heavily in favor of the candidate and if you're tactful and polite you can totally get away with driving the interview away from stupid problems. If you can't, then maybe you don't belong there and maybe that's ok. It's a win-win. A job is not a blessing, it's just a job. Unless you're starving, there's no point in pretending you're drone.
It goes even further than the "difficult to work with" vibes. If someone has 20+ years of experience and hundreds of interviews under their belts, they ought to know about candidate caliber variability and the meaning of standardization practices, aka why interview panels are setup the way they are.
As an interviewer, I might even entertain the idea of going along w/ said "two-way interview" charade, if only to see how the candidate deals w/ hiring (since for the sort of roles I evaluate for, that does come up as a job task), but I suspect that I'd see a holier-than-thou attitude that I've seen from bad interviewers and that that would be a negative flag (and, no, the "I'm not fired, I quit" thing won't work with me, because - not to brag - I'm pretty confident in my interviewee skills even without cramming leetcode)
As an interviewer, I might even entertain the idea of going along w/ said "two-way interview" charade, if only to see how the candidate deals w/ hiring (since for the sort of roles I evaluate for, that does come up as a job task), but I suspect that I'd see a holier-than-thou attitude that I've seen from bad interviewers and that that would be a negative flag (and, no, the "I'm not fired, I quit" thing won't work with me, because - not to brag - I'm pretty confident in my interviewee skills even without cramming leetcode)
> It goes even further than the "difficult to work with" vibes. If someone has 20+ years of experience and hundreds of interviews under their belts, they ought to know about candidate caliber variability and the meaning of standardization practices, aka why interview panels are setup the way they are.
Most interview panels are setup badly. Most interviewers are biased. Many technical people doing interviews just want to make themselves look smart.
A company shouldn't have one interview process, they should have several. Some do well with live coding, some do well with take-home assignments, others do well with pair-programming. All are valid ways to show skill. And each can also be something that makes the candidate incredibly uncertain and stressed.
> As an interviewer, I might even entertain the idea of going along w/ said "two-way interview" charade
It is always a two-way interview. It's not a charade. You sound extremely entitled and elitist just by saying that. The candidate has 5 other offers waiting for them that aren't being a pain in the rear like you.
Don't "entertain the idea", you are applying to the candidate as much as the candidate is applying to the company you work for. Get over yourself.
Most interview panels are setup badly. Most interviewers are biased. Many technical people doing interviews just want to make themselves look smart.
A company shouldn't have one interview process, they should have several. Some do well with live coding, some do well with take-home assignments, others do well with pair-programming. All are valid ways to show skill. And each can also be something that makes the candidate incredibly uncertain and stressed.
> As an interviewer, I might even entertain the idea of going along w/ said "two-way interview" charade
It is always a two-way interview. It's not a charade. You sound extremely entitled and elitist just by saying that. The candidate has 5 other offers waiting for them that aren't being a pain in the rear like you.
Don't "entertain the idea", you are applying to the candidate as much as the candidate is applying to the company you work for. Get over yourself.
> Most interview panels are setup badly. Most interviewers are biased. Many technical people doing interviews just want to make themselves look smart.
I'm surprised you're saying this in such a one-sided way, since you claim to interview candidates. I interview as a candidate too just like anyone else, so itemizing interview process problems is preaching to the choir. But IMHO it's disingenuous to ignore that candidates cheat, that college kids putting 10 hours on a take home assignment are very different than mother-of-three w/ 10 years experience, that bad interviewing on the part of my peers leads to me picking up someone else's slack later, and that generally speaking interview sessions are uncomfortable scenarios for everyone, no matter the format, much like code formatting styles never fully pleases everyone.
If you've been involved in defining interviewing standards, surely you must be aware that having several interview processes is even harder than standardizing on a single process: there are issues of interviewer qualification, calibration, throughput, interest, attrition, and other fun logistics things to think about. Saying every company should bend over backwards and have master interviewers fully calibrated in six different interviewing methodologies, at scale, at all times, is really not any more reasonable than a company expecting every candidate to bang out bubble sort in 30 minutes or take 10 hour take home assignments or whatever. And letting people do whatever is how you get to the Apple horror stories you see elsewhere in this comment section.
The thing about people having other options lined up goes both ways, really. Just as candidates have other options lined up, companies also have candidates lined up. In mine, HR literally needs to be mindful to not flood people w/ too many interviews each week.
> It is always a two-way interview
Oh I fully agree with the spirit here, but there is also a thing called tact. I don't go on pissing contests w/ my candidates as an interviewer and I don't go disrespecting an interviewer's time by saying "you know what, you don't know how to interview me, let me show you how I do it to you" (and yes, I believe this is tactless behavior from the perspective of myself being a candidate). If my awareness of industry standards is me being a hard-ass in your mind, I don't know what to tell you. Industry standards are what they are, ad-hoc and imperfect as they may be, and at least I try to understand the problem space and make the process better rather than just being passive aggressive about it like so many interviewing-related threads are.
When I say "I might entertain the idea", unlike sibling comments here I do actually mean exactly that: if you think you can show your skills better that way than my planned interview structure, by all means, go ahead and show me, but when I say "charade", I also mean that: I'm still evaluating you just as you are evaluating me, and if you think I'm evaluating whether "you're as smart as me(tm)", you've got the wrong impression. If your strategy as a candidate is to talk my ears off, I'm certainly open to it as an interviewer. I have had sessions like this from both sides. I'm familiar enough with this interviewing trick and how "talkers-who-dont-walk" abuse it. To be clear, I'm not saying you're one of those, but that as an interviewer, one needs to be aware of bad faith actors, and it's one of the reasons many interviewers cringe at the thought of "curveballs" like the one you suggested.
I'm surprised you're saying this in such a one-sided way, since you claim to interview candidates. I interview as a candidate too just like anyone else, so itemizing interview process problems is preaching to the choir. But IMHO it's disingenuous to ignore that candidates cheat, that college kids putting 10 hours on a take home assignment are very different than mother-of-three w/ 10 years experience, that bad interviewing on the part of my peers leads to me picking up someone else's slack later, and that generally speaking interview sessions are uncomfortable scenarios for everyone, no matter the format, much like code formatting styles never fully pleases everyone.
If you've been involved in defining interviewing standards, surely you must be aware that having several interview processes is even harder than standardizing on a single process: there are issues of interviewer qualification, calibration, throughput, interest, attrition, and other fun logistics things to think about. Saying every company should bend over backwards and have master interviewers fully calibrated in six different interviewing methodologies, at scale, at all times, is really not any more reasonable than a company expecting every candidate to bang out bubble sort in 30 minutes or take 10 hour take home assignments or whatever. And letting people do whatever is how you get to the Apple horror stories you see elsewhere in this comment section.
The thing about people having other options lined up goes both ways, really. Just as candidates have other options lined up, companies also have candidates lined up. In mine, HR literally needs to be mindful to not flood people w/ too many interviews each week.
> It is always a two-way interview
Oh I fully agree with the spirit here, but there is also a thing called tact. I don't go on pissing contests w/ my candidates as an interviewer and I don't go disrespecting an interviewer's time by saying "you know what, you don't know how to interview me, let me show you how I do it to you" (and yes, I believe this is tactless behavior from the perspective of myself being a candidate). If my awareness of industry standards is me being a hard-ass in your mind, I don't know what to tell you. Industry standards are what they are, ad-hoc and imperfect as they may be, and at least I try to understand the problem space and make the process better rather than just being passive aggressive about it like so many interviewing-related threads are.
When I say "I might entertain the idea", unlike sibling comments here I do actually mean exactly that: if you think you can show your skills better that way than my planned interview structure, by all means, go ahead and show me, but when I say "charade", I also mean that: I'm still evaluating you just as you are evaluating me, and if you think I'm evaluating whether "you're as smart as me(tm)", you've got the wrong impression. If your strategy as a candidate is to talk my ears off, I'm certainly open to it as an interviewer. I have had sessions like this from both sides. I'm familiar enough with this interviewing trick and how "talkers-who-dont-walk" abuse it. To be clear, I'm not saying you're one of those, but that as an interviewer, one needs to be aware of bad faith actors, and it's one of the reasons many interviewers cringe at the thought of "curveballs" like the one you suggested.
Absolute nonsense. In a field where very experienced people are in high demand, they'll bend over backward to offer you the job. I have references and a long history of employment. I'm not "negging" them (also, grow up), and refusing part of an interview when THEY are the one in need of talent, well, that just means they change their recruitment workflow, or lose out on talent.
I am not difficult to work with and I have a real good track record at applying for jobs, and getting job offers. Anecdotal, sure, but when an applicant gives me a good reason why they feel a certain part of the interview isn't helpful to either one of us, then I adapt. Especially if that person already got through the recruiter and tech-review filters, that means they are good.
I am not difficult to work with and I have a real good track record at applying for jobs, and getting job offers. Anecdotal, sure, but when an applicant gives me a good reason why they feel a certain part of the interview isn't helpful to either one of us, then I adapt. Especially if that person already got through the recruiter and tech-review filters, that means they are good.
Exactly. I can answer every question on my list, and you'd think any interviewer could because we've all used our interview sheets again and again and seen every caliber of answer. If you waste my time by telling me up front you're going to ask your own questions back at me, I will end the interview and thank you for your time. Not because I can't answer your questions, but because that's not what I set aside this 90 minute block of time for and you know that.
I'm cringing just thinking what it would be like working with someone who had the gall to pull that kind of nonsense.
I'm cringing just thinking what it would be like working with someone who had the gall to pull that kind of nonsense.
I don’t think the GP would want to work with you. That was the point of their comment.
Right, it's not the cringe question, it's that you don't respect mah authority in asking me back a cringe question! I think the insane people are running the asylum now.
>If you waste my time by telling me up front you're going to ask your own questions back at me
I don't see why a 20 YOE candidate with predictable capability has no right to also likewise determine how experienced, qualified or intelligent team members on the interviewing side are...
I don't see why a 20 YOE candidate with predictable capability has no right to also likewise determine how experienced, qualified or intelligent team members on the interviewing side are...
OMG the red tape at Apple is unbelievable, but this is the first time I've seen anyone mention it. On my first day at Microsoft, I checked in code. At Apple it took nearly two weeks to get granted separate access to the apps's sourcecode, secret OS version, secret Xcode version, secret new OS headers (for some reason this was a separate line item), upcoming hardware versions (which I never saw anyway).
Once up and running as a senior engineer with tons of experience, I had no autonomy and wasn't allowed to do something as trivial as add a comment without a bug database number and two code reviews.
Once up and running as a senior engineer with tons of experience, I had no autonomy and wasn't allowed to do something as trivial as add a comment without a bug database number and two code reviews.
> wasn't allowed to do something as trivial as add a comment without a bug database number and two code reviews.
I mean... how else? If this is iOS for example, this potentially goes out to in the order of hundreds of millions, or even a billion or so, user devices. If you want the due diligence process not to apply for a comment, where do you draw the line? (Not withstanding that the comment may be wrong, or have an effect anyway. Yes, weird things happen at scale.)
Even if there were a class of code changes that were deemed not to need review and a "bug database number", with every build on every lever of the multi level builds, changes often need to be removed, quickly. Because they cause bad bugs, or because they collided with other changes, or for any other reason.
You want to be able to remove that change, however innocuous it may have seemed, in the quickest and most efficient way possible. Sometimes across multiple builds. Without upsetting hundreds of other engineers that have made changes as well. For that, "random commit without metadata" does not cut it.
But nobody is going to be upset if you simply add your comment change or whatever reasonable cleanup change to another change in the same project, in order to not have to open a new bug just for cleanup for example. It will then be reviewed, and have its fate tied in case of problems, with the other code. When I worked at another FAANG, it was exactly like that as well.
I mean... how else? If this is iOS for example, this potentially goes out to in the order of hundreds of millions, or even a billion or so, user devices. If you want the due diligence process not to apply for a comment, where do you draw the line? (Not withstanding that the comment may be wrong, or have an effect anyway. Yes, weird things happen at scale.)
Even if there were a class of code changes that were deemed not to need review and a "bug database number", with every build on every lever of the multi level builds, changes often need to be removed, quickly. Because they cause bad bugs, or because they collided with other changes, or for any other reason.
You want to be able to remove that change, however innocuous it may have seemed, in the quickest and most efficient way possible. Sometimes across multiple builds. Without upsetting hundreds of other engineers that have made changes as well. For that, "random commit without metadata" does not cut it.
But nobody is going to be upset if you simply add your comment change or whatever reasonable cleanup change to another change in the same project, in order to not have to open a new bug just for cleanup for example. It will then be reviewed, and have its fate tied in case of problems, with the other code. When I worked at another FAANG, it was exactly like that as well.
That actually sounds pretty par for the course in many big tech companies.
Nah. I've worked at other FAANG companies and I'm afraid that none had anything close to the Apple level of red tape. I have barely scratched the surface of describing it.
At the end of the day, you applied for the job at a company whose success is at-least partially based on the structure and rules that were instituted by those who came before you. It could be that they were put in for a very good reason. I'm all for re-evaluating rules and making modifications, but erring on the side of caution is probably a good idea as well. Just my 2c, not necessarily disagreeing with your opinion.
No one knows the degree of red tape or dysfunctions at Apple until they're actually in the company. The aura of secrecy masks what's going on.
Woah, we got a badass over here. Seriously they have 1,000 other qualified candidates lined up right behind you. I'm sure they appreciate your time and then end the interview.
I also think this comes across as someone being pretentious and arrogant, and could be a no-hire, but there’s a nugget of truth in this: interviews are two-way streets, and getting a feel for your coworkers and your environment can be as important as landing the job.
Also
> Seriously they have 1,000 other qualified candidates lined up right behind you.
I’d kill to have ten qualified candidates to interview. It’s a seller’s market.
Also
> Seriously they have 1,000 other qualified candidates lined up right behind you.
I’d kill to have ten qualified candidates to interview. It’s a seller’s market.
As an interviewer I've given you a heads up before the meeting what is being tested for. Some time to practice, do pre-work, research the company, etc.
Dumping at the start of that meeting out of the blue this criteria, is not a two-way street equal reciprocation of that respect. If you'd kill for ten candidates, you can have him. I've had ~230 for 2 position this week and I'm testing for EQ also. Maybe changing requirements on people at the last minute fits in your work culture.
Dumping at the start of that meeting out of the blue this criteria, is not a two-way street equal reciprocation of that respect. If you'd kill for ten candidates, you can have him. I've had ~230 for 2 position this week and I'm testing for EQ also. Maybe changing requirements on people at the last minute fits in your work culture.
~250 Candidates? Sure mate, I'd be surprised if at the end of your application process 5 of them remain and are still available.
Companies are having a very hard time finding software engineers. For the first time in the history of the market, employee retention budgets are skyrocketing because recruiting is so expensive and hard. It's not rare to hear software engineers getting a sudden 30% raise out of the blue.
Because they know we're in high demand, and they know that if we switch jobs we'll get a 30% raise, at a minimum.
Companies are having a very hard time finding software engineers. For the first time in the history of the market, employee retention budgets are skyrocketing because recruiting is so expensive and hard. It's not rare to hear software engineers getting a sudden 30% raise out of the blue.
Because they know we're in high demand, and they know that if we switch jobs we'll get a 30% raise, at a minimum.
[deleted]
If you truly have a position that is averaging 100 applicants, you are hiring on the margins.
You either have a position that is so elite and aspirational that it is paid accordingly and people are flocking to it - and good luck filtering out the majority of resumes that Dunning-Krugered their way into your inbox before the elite candidate moves on. Or, you have a position with requirements so low that you can easily get candidates by the bucketful and take your time to sift through to find a diamond.
Most of us aren’t hiring on the margins.
You either have a position that is so elite and aspirational that it is paid accordingly and people are flocking to it - and good luck filtering out the majority of resumes that Dunning-Krugered their way into your inbox before the elite candidate moves on. Or, you have a position with requirements so low that you can easily get candidates by the bucketful and take your time to sift through to find a diamond.
Most of us aren’t hiring on the margins.
> Seriously they have 1,000 other qualified candidates lined up right behind you.
That is really not the case right now. It's REALLY hard to even find candidates in the first place. Especially people with OPs years of experience...
That is really not the case right now. It's REALLY hard to even find candidates in the first place. Especially people with OPs years of experience...
Sounds like you should open a recruiting and placement agency if you have 1,000 of what everyone else is searching for high and low with limited success.
I'm not a badass, I am just laying out a baseline: I know what I'm talking about. That's all. And no, many companies don't have 1k applicants that are qualified. They have 5000 applicants in the SF area, 4900 of them are unqualified, 80 who are qualified can't write English, of the remaining 20 candidates only 8 are still on the market once you reach them, 4 pass your filters, 2 accept a job offer, and only 1 of them shows up.
That's far more realistic. In today's world, we're not looking for jobs, jobs are looking for us. Desperately so.
That's far more realistic. In today's world, we're not looking for jobs, jobs are looking for us. Desperately so.
They don't anymore! Candidates are scarce these days.
> Seriously they have 1,000 other qualified candidates lined up right behind you
I really doubt it.
I really doubt it.
It's interesting how many people replied to this rushing to defend algorithmic hazing. Sure this is sort of a "then the whole class started clapping" type post, but there is some merit buried in here.
Somebody with 20 years experience I would like to explore that they are not a bullshit artist and not subject them to worthless leetcode questions that some desperate 24 year old will cram, pretend they never saw the question before and spam out on a whiteboard.
Somebody with 20 years experience I would like to explore that they are not a bullshit artist and not subject them to worthless leetcode questions that some desperate 24 year old will cram, pretend they never saw the question before and spam out on a whiteboard.
So you mentioned you worked at Apple... twice, plus a bunch of other high profile companies & with 20 years of experience your interviewee techniques aren't really that applicable to almost everyone here. If someone ever responded like you say you do at the start of an interview my notes would read something like "lots of great experience, seems incredibly intelligent and skilled, total pretentious a-hole". You state a lot of desires for your employer and coworkers; I want to work with developers who are skilled, humble, joyful and nice.
And Booking, now also twice. What can I say, Apple was fun. Stayed for 12 months and then I left.
> If someone ever responded like you say you do at the start of an interview my notes would read something like "lots of great experience, seems incredibly intelligent and skilled, total pretentious a-hole".
Well, I wouldn't act like I write on an anonymous online forum like this, obviously.
So far I would say that most of my ex-colleagues would describe me as someone who is quiet, listens well, makes lots of notes on a paper, has a fancy pen with ink, and is surprisingly non-hipster despite all that.
I'm very involved with helping other developers in my social network getting the most out of job interviews and salary negotiations. I know the right ways of getting the most out of performance reviews and how to nail an interview that would otherwise make one uncomfortable.
But, point taken.
> If someone ever responded like you say you do at the start of an interview my notes would read something like "lots of great experience, seems incredibly intelligent and skilled, total pretentious a-hole".
Well, I wouldn't act like I write on an anonymous online forum like this, obviously.
So far I would say that most of my ex-colleagues would describe me as someone who is quiet, listens well, makes lots of notes on a paper, has a fancy pen with ink, and is surprisingly non-hipster despite all that.
I'm very involved with helping other developers in my social network getting the most out of job interviews and salary negotiations. I know the right ways of getting the most out of performance reviews and how to nail an interview that would otherwise make one uncomfortable.
But, point taken.
>You state a lot of desires for your employer and coworkers
They also mention bubble sort a lot. Bubble sort.
They also mention bubble sort a lot. Bubble sort.
Why bubble sort? Why?!?!?
These people are offended that you would question the competency of the employer and the interviewers. They say that you need to adopt a more servile attitude.
Yeah, it's a filter we actually got from management at one company. They were looking for specifically agreeable type of developers. It was a consultancy and they needed to put 5 more developers on one of their big clients, and the client was getting sick of the previous people we had there; they were constantly fighting back against their idiots of managers.
Boss wants employees to write many hours, not have a weekly phone call from the client asking to replace another team member...
Agreeable people also stick around longer, because they think loyalty pays, and agreeable people rarely negotiate a good salary.
Boss wants employees to write many hours, not have a weekly phone call from the client asking to replace another team member...
Agreeable people also stick around longer, because they think loyalty pays, and agreeable people rarely negotiate a good salary.
Spot on. And these are companies to avoid.
There are lots of un-googleable problems out there. These questions are meant to identify the people that will probably fail to solve any non-trivial programming challenge (and maybe even some of the trivial ones).
I'm not really opinionated about whether or not you should do algorithmic stuff in the interview, but I don't agree with your reasoning here.
I see chatter about how most problems can be solved with google and your CS teacher lied to you (usually on reddit, less so on HN). My experiences have not matched this. I'd estimate that a good 40-80% of my problems don't have a solution on google. It's pretty rarely an algorithmic problem though.
If you're playing that game, are there reasons that you'd ever be copy pasting sorting algorithms from the internet? Why bubble? Don't most programming languages have libraries available to help (especially python)? I work in an area with very little sorting, but I can't imagine myself doing that in a higher level language, or even in C.
I'm not really opinionated about whether or not you should do algorithmic stuff in the interview, but I don't agree with your reasoning here.
I see chatter about how most problems can be solved with google and your CS teacher lied to you (usually on reddit, less so on HN). My experiences have not matched this. I'd estimate that a good 40-80% of my problems don't have a solution on google. It's pretty rarely an algorithmic problem though.
If you're playing that game, are there reasons that you'd ever be copy pasting sorting algorithms from the internet? Why bubble? Don't most programming languages have libraries available to help (especially python)? I work in an area with very little sorting, but I can't imagine myself doing that in a higher level language, or even in C.
My experience with problems that can't be solved with a Google search is limited. I tend to use existing technologies and I stick with an architecture that has been around for long enough to have proper support online.
Still, sometimes I run into limitations with regard to TypeScript, for example. If that happens I'll go over the problem with more experienced developers. It'll be a pair-programming thing for several reasons: two pairs of eyes and two brains see and think more than 1, and you both learn something new, and you both have a little more brainpower available because you want to look good. At least I do my best a little more ;)
> If you're playing that game, are there reasons that you'd ever be copy pasting sorting algorithms from the internet? Why bubble? Don't most programming languages have libraries available to help (especially python)? I work in an area with very little sorting, but I can't imagine myself doing that in a higher level language, or even in C.
It's a silly example, I don't care what algorithm we're talking about. And no, many languages lack any sort of built-in sorting solutions. JavaScript (front-end and Node.js), for example, requires external libraries for performant solutions.
Still, sometimes I run into limitations with regard to TypeScript, for example. If that happens I'll go over the problem with more experienced developers. It'll be a pair-programming thing for several reasons: two pairs of eyes and two brains see and think more than 1, and you both learn something new, and you both have a little more brainpower available because you want to look good. At least I do my best a little more ;)
> If you're playing that game, are there reasons that you'd ever be copy pasting sorting algorithms from the internet? Why bubble? Don't most programming languages have libraries available to help (especially python)? I work in an area with very little sorting, but I can't imagine myself doing that in a higher level language, or even in C.
It's a silly example, I don't care what algorithm we're talking about. And no, many languages lack any sort of built-in sorting solutions. JavaScript (front-end and Node.js), for example, requires external libraries for performant solutions.
one of the things interviewers look for is great questions from the candidate. servile drones make fine code-monkeys. but if you want to put it all together, you'll need to show some attitude. pretentious? maybe, but efficiency is key. have you ever seen the old Letterman gag "don't call me Chief"? Letterman interviews people on the street calling them Chief, and the person to win the game must day "stop calling me chief".
> servile drones make fine code-monkeys.
and quite often the desire is to have servile drones.
and quite often the desire is to have servile drones.
[deleted]
That's a great way to turn the process into a zero sum game. I don't understand why people do it.
I once had a phone interview at a startup. The interviewer showed up 20 minutes late. And the first thing he said was, "I was in a meeting and before you ask, I can't tell you anything about it because then I have to kill you".
??? I just hung up.
I once had a phone interview at a startup. The interviewer showed up 20 minutes late. And the first thing he said was, "I was in a meeting and before you ask, I can't tell you anything about it because then I have to kill you".
??? I just hung up.
It was a joke. The joke being that they received top secret confidential information, like in a spy movie.
> Before I am presented with a dumbass interviewer who throws a ridiculous question my way about algorithmic stuff, I prepare them: "Since we are both seeing if the other party is competent, I want you to know that I want you to also solve my questions. They will be slightly more difficult than the questions you pose to me."
And that is extremely arrogant. I would end interview right now. I don't care who you are and how much experience you have, I believe in "no asshole" rule.
You are interviewing to work at the company. The relationship is between you and the company and not between you and the interviewer. He has particular job to do which does not include responding to your out there whims.
He is in a tough position, most likely with much less experience than you and still asked to do a difficult job of judging your experience.
Be kind to people. Show your maturity by understanding what is the other person's role in the process.
If you have so much knowledge and experience as you claim, you should have no problem going through the process -- your willingness to go out of your way to do this kind of shit does not show you are going to be nice person to work with.
> I would never ask a question I can't also answer from the top of my head
That is prerequisite, but not yet full solution.
You are asking candidates for things you know which means you are comparing their experience to yours. What if they have different experience and met different problems?
Ideally, you want to answer a question "Can they be productive at their new position?" which is a different question from "Do they know everything I do?"
I always remind myself that it is likely every single candidate I interviewed knows something I do not.
> Having worked at Apple, it doesn't surprise me one bit how slow they are developing simple features and fixing simple bugs. It's a red-tape hell full of not-very pragmatic engineers that are way too smart for the good of the company.
Have you ever tried actually figuring out how make it more efficient rather than just complain at the engineers you are working with? Have you always been super pragmatic, fast engineer that can accomplish things at startup speeds? Or have you been just as everybody else, constantly complaining how productive you could be if only everybody around you were not dragging you?
And that is extremely arrogant. I would end interview right now. I don't care who you are and how much experience you have, I believe in "no asshole" rule.
You are interviewing to work at the company. The relationship is between you and the company and not between you and the interviewer. He has particular job to do which does not include responding to your out there whims.
He is in a tough position, most likely with much less experience than you and still asked to do a difficult job of judging your experience.
Be kind to people. Show your maturity by understanding what is the other person's role in the process.
If you have so much knowledge and experience as you claim, you should have no problem going through the process -- your willingness to go out of your way to do this kind of shit does not show you are going to be nice person to work with.
> I would never ask a question I can't also answer from the top of my head
That is prerequisite, but not yet full solution.
You are asking candidates for things you know which means you are comparing their experience to yours. What if they have different experience and met different problems?
Ideally, you want to answer a question "Can they be productive at their new position?" which is a different question from "Do they know everything I do?"
I always remind myself that it is likely every single candidate I interviewed knows something I do not.
> Having worked at Apple, it doesn't surprise me one bit how slow they are developing simple features and fixing simple bugs. It's a red-tape hell full of not-very pragmatic engineers that are way too smart for the good of the company.
Have you ever tried actually figuring out how make it more efficient rather than just complain at the engineers you are working with? Have you always been super pragmatic, fast engineer that can accomplish things at startup speeds? Or have you been just as everybody else, constantly complaining how productive you could be if only everybody around you were not dragging you?
Found the victim-blamer, who blames them for speaking up for themselves.
It is not speaking up, it is just complaining.
Speaking up is aimed at fixing the problem. People who "speak up" do it because they believe it is necessary to create publicity around the problem to get it fixed.
Speaking up is aimed at fixing the problem. People who "speak up" do it because they believe it is necessary to create publicity around the problem to get it fixed.
There is no way to “fix the problem” as the interviewee, unless you have invented a mind-control device. You can merely say no, and only if you are a desirable candidate can it have an effect other than “pushing on a string.”
I can’t think of a better approach than the golden rule here.
I can’t think of a better approach than the golden rule here.
> And that is extremely arrogant. I would end interview right now. I don't care who you are and how much experience you have, I believe in "no asshole" rule.
I'm not being an asshole, the interview goes both ways. I want to know who I'm working with and whether they practice what they test for.
> You are interviewing to work at the company. The relationship is between you and the company and not between you and the interviewer. He has particular job to do which does not include responding to your out there whims.
Oh come on, stop being so subservient. It's just a company.
The company is trying to convince me to work for them. If they want to know about what I can do for them, I have a lengthy resume and 5+ references they can call.
> He is in a tough position, most likely with much less experience than you and still asked to do a difficult job of judging your experience.
It's not a difficult job, though. Their recruiter can call my references, she can check if I worked at the companies I listed, their technical people can absolutely ask me relevant questions. But if they go into the realm of leetcode nonsense, then I am absolutely going to play that game with them.
And I don't really care if I get the job or not, I can afford to not work for about 20 months if I need to, and if I reach out to any of my on-call recruiters they'll have 5 job OFFERS for me in the next 14 days.
> Be kind to people. Show your maturity by understanding what is the other person's role in the process.
Well, I'm tactful in real life, trust me. My anonymous discourse on a forum like this isn't my conduct in real life, obviously.
> I always remind myself that it is likely every single candidate I interviewed knows something I do not.
That's a real good mindset, and I think it's guaranteed. Many junior developers still teach me a lot every day in my work.
---
> Have you ever tried actually figuring out how make it more efficient rather than just complain at the engineers you are working with? Have you always been super pragmatic, fast engineer that can accomplish things at startup speeds? Or have you been just as everybody else, constantly complaining how productive you could be if only everybody around you were not dragging you?
I did.
When I got into Apple I was one of the first to introduce them to React Native for one of their in-store specialist apps that were also customer facing. High requirements for quality. I setup a small team (1 back-end dev, 1 front-end, 1 full-stack, 1 designer, 1 product manager) and we finished the software to the requirements in ~4 months where we were given 12 months.
And I think I'm extremely pragmatic, and that it's in my nature, historically speaking. I'm detail-oriented, fast, creative, and while I have my preferences, I easily change my mind when faced with new or better information.
And if I can't change or improve what I do a company (it didn't work at First American, for example), I'll just leave. I'll definitely try, but it's easy to see unbreakable walls of politics and invested third-parties who just want to write and invoice hours, not results.
A local bank I worked for, too. They promised me the world and gave me "unlimited power" to improve everything I wanted. Turns out, the unlimited power only went up to my own level, and I was still 5 levels below the hyper-social CTO who didn't know anything about the technology we were working with.
I don't like complaining, I like solutions. I bring solutions to the table. And it takes more than just me to get them implemented, especially in larger companies...
I'm not being an asshole, the interview goes both ways. I want to know who I'm working with and whether they practice what they test for.
> You are interviewing to work at the company. The relationship is between you and the company and not between you and the interviewer. He has particular job to do which does not include responding to your out there whims.
Oh come on, stop being so subservient. It's just a company.
The company is trying to convince me to work for them. If they want to know about what I can do for them, I have a lengthy resume and 5+ references they can call.
> He is in a tough position, most likely with much less experience than you and still asked to do a difficult job of judging your experience.
It's not a difficult job, though. Their recruiter can call my references, she can check if I worked at the companies I listed, their technical people can absolutely ask me relevant questions. But if they go into the realm of leetcode nonsense, then I am absolutely going to play that game with them.
And I don't really care if I get the job or not, I can afford to not work for about 20 months if I need to, and if I reach out to any of my on-call recruiters they'll have 5 job OFFERS for me in the next 14 days.
> Be kind to people. Show your maturity by understanding what is the other person's role in the process.
Well, I'm tactful in real life, trust me. My anonymous discourse on a forum like this isn't my conduct in real life, obviously.
> I always remind myself that it is likely every single candidate I interviewed knows something I do not.
That's a real good mindset, and I think it's guaranteed. Many junior developers still teach me a lot every day in my work.
---
> Have you ever tried actually figuring out how make it more efficient rather than just complain at the engineers you are working with? Have you always been super pragmatic, fast engineer that can accomplish things at startup speeds? Or have you been just as everybody else, constantly complaining how productive you could be if only everybody around you were not dragging you?
I did.
When I got into Apple I was one of the first to introduce them to React Native for one of their in-store specialist apps that were also customer facing. High requirements for quality. I setup a small team (1 back-end dev, 1 front-end, 1 full-stack, 1 designer, 1 product manager) and we finished the software to the requirements in ~4 months where we were given 12 months.
And I think I'm extremely pragmatic, and that it's in my nature, historically speaking. I'm detail-oriented, fast, creative, and while I have my preferences, I easily change my mind when faced with new or better information.
And if I can't change or improve what I do a company (it didn't work at First American, for example), I'll just leave. I'll definitely try, but it's easy to see unbreakable walls of politics and invested third-parties who just want to write and invoice hours, not results.
A local bank I worked for, too. They promised me the world and gave me "unlimited power" to improve everything I wanted. Turns out, the unlimited power only went up to my own level, and I was still 5 levels below the hyper-social CTO who didn't know anything about the technology we were working with.
I don't like complaining, I like solutions. I bring solutions to the table. And it takes more than just me to get them implemented, especially in larger companies...
This reads like a guy who got rejected from Apple and is now venting.
Funny thing about apple last time I interviewed there, everyone is an independent interview team. If you want to work at apple, you can, you just have to keep on interviewing and interviewing and interviewing and eventually you'll get a bite.
Did not get rejected, and I loved working at Apple despite the red tape. The only reason I no longer work there is because I moved to a different continent :)
IMO there is a difference between production code and whiteboard code. Nobody expects candidates to come up with ready-to-ship production code in 10 minutes. I don't care much for arguments about which interviewing style is better. If you find success using your method, I'm happy for you, and I only care about results. Asking someone to write code has never let me down. It has exposed a lot of charlatans who puff up their resume taking credit for their teams work, but when you ask them detailed questions they can't back-up their claimed technical prowess.
> I mean, I'd rather have developers on my team who Google "bubble sort python" and go for a tried and tested open-source solution.
I think it's pretty well known that the question, or the actual question for which this bubble sort question is just an example, is usually more about how good you are at solving a particular problem.
For example, I'd rather not have developers on my team who Google "bubble sort python" and go for a tried and tested open-source solution, because I want my developers to know that bubble sort is an O(n^2) toy algorithm mostly used as an example for an intentionally bad sorting algorithm.
I think it's pretty well known that the question, or the actual question for which this bubble sort question is just an example, is usually more about how good you are at solving a particular problem.
For example, I'd rather not have developers on my team who Google "bubble sort python" and go for a tried and tested open-source solution, because I want my developers to know that bubble sort is an O(n^2) toy algorithm mostly used as an example for an intentionally bad sorting algorithm.
I don't see the problem. Writing code by hand has its roots in the early days of computing with punch cards and C is ubiquitous. I suppose the comment was somewhat snide but if your skin is that thin are you able to work on a team without becoming the problem?
I don't understand why "roots in the early days of computing" is inherently good. We've learned a lot since those days. As a fun example, imagine defending storing plaintext passwords "because it has it's roots in the early days of computing".
Other than "because we've always done it that way", what do you learn about a candidate in a 30-60 minute whiteboard interview where you ask them to implement something they'll never have to implement on the job, while restricting them from all of the resources they have been trained to rely on (internet access, man pages, etc.)?
Other than "because we've always done it that way", what do you learn about a candidate in a 30-60 minute whiteboard interview where you ask them to implement something they'll never have to implement on the job, while restricting them from all of the resources they have been trained to rely on (internet access, man pages, etc.)?
Sorting algorithms are taught as part of every CS degree and C is still used today. The only real change is there are a lot more low-quality programmers than there used to be. If you have to cheat to pass a test I think that would tell the interviewers a lot. Any code monkey can search StackOverflow.
>Sorting algorithms are taught as part of every CS degree and C is still used today.
I still don't understand what you're learning from the 30-60 minute interview. If you want to know if someone has a CS degree, look at their resume.
>The only real change is there are a lot more low-quality programmers than there used to be.
You'll need some data to back that one up.
>If you have to cheat to pass a test I think that would tell the interviewers a lot.
I would consider someone smart if they use every resource available to them to solve the problem presented to them. You consider it cheating. What a weird way of thinking -- just rote memorization for everything in life? Everything must be from first principles? Sounds tedious and inefficient to me.
Smart people realize that other smart people exist, and might even have valuable ideas or solutions applicable to their own problems.
I still don't understand what you're learning from the 30-60 minute interview. If you want to know if someone has a CS degree, look at their resume.
>The only real change is there are a lot more low-quality programmers than there used to be.
You'll need some data to back that one up.
>If you have to cheat to pass a test I think that would tell the interviewers a lot.
I would consider someone smart if they use every resource available to them to solve the problem presented to them. You consider it cheating. What a weird way of thinking -- just rote memorization for everything in life? Everything must be from first principles? Sounds tedious and inefficient to me.
Smart people realize that other smart people exist, and might even have valuable ideas or solutions applicable to their own problems.
People lie on resumes. I don't need data to give my educated opinion. Rote memorization/learning is extremely valuable, disputing that fact is ridiculous. Stupid people also exist and unfortunately most companies need to weed them out, at least from certain positions.
While your brain is busy upkeeping your memorized minutia, I'll be on bigocheatsheet.com looking up big-O notation for every single algorithm in seconds, and keeping more of my brain on the actual problems at hand.
Degrees are really straightforward to verify (at least from any accredited domestic school), a standard new hire background check would catch this. Obviously tech companies just don't think the degree is a super valuable signal, which I get. But I think they've turned around and placed too much emphasis on these whiteboard interviews.
Memorization can certainly be important. Memorizing random algorithms that you will never actually use during the job is less so. Conversely, other skills are important too. Poorly executed whiteboard interviews will select crammers who lack many other skills.
Memorization can certainly be important. Memorizing random algorithms that you will never actually use during the job is less so. Conversely, other skills are important too. Poorly executed whiteboard interviews will select crammers who lack many other skills.
I have a CS degree and I develop for the web. Want to know how often I write sorting algorithms for my job? Never, nada, none in 3 years out of school. Could I if asked? Absolutely. First I would question why we aren't using a pre-written and pre-tested library, but if convinced I would pull up google and take some time to write a performant sorting algorithm with the knowledge we all have free access to.
Meanwhile a dev can study leetcode for months and land a job where it turns out they have little to no experience in the actual work they will be doing day-to-day. Who would you rather hire?
Meanwhile a dev can study leetcode for months and land a job where it turns out they have little to no experience in the actual work they will be doing day-to-day. Who would you rather hire?
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?