5 ms·

My impression of the facebook interview experience was that it is specifically selecting people that were calm under pressure and well rehearsed. They are testi

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.

kazinator 5y ago
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?
- burntoutfire 5y ago
  > 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?
  - creamytaco 5y ago
    They do, we had plenty of dead weight at Google, usually acquihires.
neffy 5y ago
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.
- hpoe 5y ago
  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.
  - exdsq 5y ago
    I think JPMorgan asks questions like that - I remember seeing them listed on a prep website once
  - fzil 5y ago
    AFAIK around 2010ish Google asked a bunch of these kind of questions.
yodsanklai 5y ago
> 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.
whatshisface 5y ago
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.
- vanusa 5y ago
  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?
lhorie 5y ago
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.

kazinator 5y ago

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?

burntoutfire 5y ago
> 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?
- creamytaco 5y ago
  They do, we had plenty of dead weight at Google, usually acquihires.

neffy 5y ago

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.

hpoe 5y ago
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.
- exdsq 5y ago
  I think JPMorgan asks questions like that - I remember seeing them listed on a prep website once
- fzil 5y ago
  AFAIK around 2010ish Google asked a bunch of these kind of questions.

yodsanklai 5y ago

> 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.

whatshisface 5y ago

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.

vanusa 5y ago
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?

lhorie 5y ago

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.