5 ms·

I wonder which came first? Did they hire those people because they implemented leetcode style interviews, or did they implement those interviews because they or

I wonder which came first? Did they hire those people because they implemented leetcode style interviews, or did they implement those interviews because they originally hired or were founded by ex-bigco folks that simply did what they knew?

brandall10 4y ago
I notice quite a few early stage startups that recruit w/ large initial funding rounds (ie. a $20-40M series A) almost invariably have a note about how their founders are ex-FAANG. I can't help but believe it helps a ton w/ funding, professional networks, team building, etc. Again, no different than having an Ivy League education. There are big advantages to scope/reach/opportunities in the industry.
- exdsq 4y ago
  Signaling is definitely a thing!
jboy55 4y ago
Perhaps there's another collectively shared work experience that also created leetcode style interviews. That is dealing with someone who has a degree, can speak well of what it takes to code, but who cannot code to save their life. I have known more than a dozen such "engineers". That's the reason you code during an interview, I think the emphasis on optimal O(N) is just a set of engineers who don't believe it should be "that easy" and doesn't really help produce more of a signal. My coding question, for example, You have a music player that should be playing a 900 song list randomly. You notice that you keep hearing a song being repeated during your drive and you are curious if its truly random. You also keep hitting skip in the hopes a particular song comes up. Write a piece of code that simulates this. You should tell me three things; 1) the number of songs played before a repeat occurs 2) how many songs needed to be played before you played them all 3) after you succeed in playing them all, how many times has the most common song been played. You can use libraries if you know them, and you can use the built in sort method in the language, I will google it for you if you don't remember the syntax.
- drugstorecowboy 4y ago
  But.. why? Does that reflect anything close to the job they would be doing? Is handicapping someone in every way (You will google it for them), putting them on the spot in an already tense situation and expecting them to code while you watch the way that literally any software job works? This is the insanity to me, "Here, do this contrived task that doesn't represent anything you will be doing... to prove that you can do the job" I once had a whiteboard interview for a senior engineer position where they demanded that I write it in syntactically correct python, indentions and all, on the whiteboard. I'm trying to talk about code at a high level with them meanwhile they are deducting points because I assigned a dictionary key directly vs. using the dictonary's method. It turned me off to the company as a whole and the entire interview went downhill from there.
  - jackblemming 4y ago
    There is a class of engineer who have little performance anxiety by nature. They simply don’t care and are normally blunt types who love algorithms. And they are, frankly, pretty bad at writing code because they have little empathy for the reader and greatly inflated sense of self worth. They’re the kind to use complicated C++ features or algorithms for little reason. Essentially, smart idiots. They also believe in silly things like LC being a fair and rational way to evaluate candidates and don’t see the bias at all. “Eugh she’s an ugly woman, I think I’ll give her the LC hard and little help.” There is another class who realizes how stupid LC is, but are happy to play the game to quickly accumulate power and prestige. They usually have psychopathic tendencies and aren’t great coworkers. LC is great at hiring these types. Feel free to stick to it if you enjoy having them as coworkers.
  - krisoft 4y ago
    > But.. why? Does that reflect anything close to the job they would be doing? Yes? Yes. Figuring out how to make a computer solve problems is very much the job of a software developer. They will only encounter harder and less well defined tasks in their actual job. If they can’t do this and you hire them that is like hiring an opera singer who is mute, or a baker who is deadly alergic to flour. > putting them on the spot in an already tense situation and expecting them to code while you watch There are mitigating factors one can do. We make sure our hiring managers let the candidates know that there will be a coding challenge. We ask the candidates if they prefer to chat while they work through the task or prefer to be left alone and we acomodate what they choose. We let them know that whatever style they prefer it won’t change anything. > meanwhile they are deducting points because I assigned a dictionary key directly vs. using the dictonary's method That sounds very unpleasant. Sorry to hear that. Interviews are a two way street. You are interviewed and at the same time you are interviewing them. I think you were right in judging them, and you dodged a bulet there. By the sound of it you are a talented, and capable developer. It might be that you can’t imagine it, but there are people who apply for developer jobs, has a really good ability to talk about the job, they seemingly have the right experience, yet somehow they can’t program even super simple tasks. Even after you give them every acommodation immaginable to humankind. If you haven’t seen this yet you won’t believe it. If you have seen it you want a filter against this particular kind of candidate. I’m not saying that this filter goes always well. Every filter ever invented had both false positives and false negatives. We might lose a briliant developer because some quirk of the task throws them. It is sad. We are trying to minimise the chances of this, but it certainly happens.
dekhn 4y ago
The predecessors to leetcode questions were being asked, for example, in PhD defense dissertations as well as some that were highly specific to the company in questions (sort 2MB of data 1MB RAM). Many of the problems are basically late-undergrad, early-graduate CS student problems.
- astrange 4y ago
  Do PhD defenses actually involve asking random tech questions instead of what's in the dissertation? Seems like if they're going to fail that, you already have bigger problems.
  - dekhn 4y ago
    My PhD was in biophysics and the questions ranged widely outside my dissertation (in my case, you actually do a defense to proceed to work on your PhD, then write your dissertation and give a final talk; there's no way, unless your advisor rejects your dissertation, that your phd wouldn't be awarded. Other programs rear-load the process and have a real "defense" at the end, which is crazy if you think about it. At one point in my thesis defense, I derived several equations I hadn't seen before, on the fly, such as "What is the time resolved fluorescence of a fluorophore in 4-dimensional space?" and finally understanding ergodicity (https://en.wikipedia.org/wiki/Ergodicity https://en.wikipedia.org/wiki/Ergodicity). My defense wasn't about determining if I was an expert and qualified to write a dissertation in my field (my questioners already knew that), but to determine if I was a well-rounded general intelligence capable of out-of-task prediction.
    - arcanus 4y ago
      This sounds like the qualifying examination. In my phd experience in the USA we had oral qualifying examinations which involved whiteboard derivations. The thesis defense after writing was really mostly focused on probing the results in the thesis.

brandall10 4y ago

I notice quite a few early stage startups that recruit w/ large initial funding rounds (ie. a $20-40M series A) almost invariably have a note about how their founders are ex-FAANG. I can't help but believe it helps a ton w/ funding, professional networks, team building, etc. Again, no different than having an Ivy League education. There are big advantages to scope/reach/opportunities in the industry.

exdsq 4y ago
Signaling is definitely a thing!

jboy55 4y ago

Perhaps there's another collectively shared work experience that also created leetcode style interviews. That is dealing with someone who has a degree, can speak well of what it takes to code, but who cannot code to save their life. I have known more than a dozen such "engineers". That's the reason you code during an interview, I think the emphasis on optimal O(N) is just a set of engineers who don't believe it should be "that easy" and doesn't really help produce more of a signal. My coding question, for example, You have a music player that should be playing a 900 song list randomly. You notice that you keep hearing a song being repeated during your drive and you are curious if its truly random. You also keep hitting skip in the hopes a particular song comes up. Write a piece of code that simulates this. You should tell me three things; 1) the number of songs played before a repeat occurs 2) how many songs needed to be played before you played them all 3) after you succeed in playing them all, how many times has the most common song been played. You can use libraries if you know them, and you can use the built in sort method in the language, I will google it for you if you don't remember the syntax.

drugstorecowboy 4y ago
But.. why? Does that reflect anything close to the job they would be doing? Is handicapping someone in every way (You will google it for them), putting them on the spot in an already tense situation and expecting them to code while you watch the way that literally any software job works? This is the insanity to me, "Here, do this contrived task that doesn't represent anything you will be doing... to prove that you can do the job" I once had a whiteboard interview for a senior engineer position where they demanded that I write it in syntactically correct python, indentions and all, on the whiteboard. I'm trying to talk about code at a high level with them meanwhile they are deducting points because I assigned a dictionary key directly vs. using the dictonary's method. It turned me off to the company as a whole and the entire interview went downhill from there.
- jackblemming 4y ago
  There is a class of engineer who have little performance anxiety by nature. They simply don’t care and are normally blunt types who love algorithms. And they are, frankly, pretty bad at writing code because they have little empathy for the reader and greatly inflated sense of self worth. They’re the kind to use complicated C++ features or algorithms for little reason. Essentially, smart idiots. They also believe in silly things like LC being a fair and rational way to evaluate candidates and don’t see the bias at all. “Eugh she’s an ugly woman, I think I’ll give her the LC hard and little help.” There is another class who realizes how stupid LC is, but are happy to play the game to quickly accumulate power and prestige. They usually have psychopathic tendencies and aren’t great coworkers. LC is great at hiring these types. Feel free to stick to it if you enjoy having them as coworkers.
- krisoft 4y ago
  > But.. why? Does that reflect anything close to the job they would be doing? Yes? Yes. Figuring out how to make a computer solve problems is very much the job of a software developer. They will only encounter harder and less well defined tasks in their actual job. If they can’t do this and you hire them that is like hiring an opera singer who is mute, or a baker who is deadly alergic to flour. > putting them on the spot in an already tense situation and expecting them to code while you watch There are mitigating factors one can do. We make sure our hiring managers let the candidates know that there will be a coding challenge. We ask the candidates if they prefer to chat while they work through the task or prefer to be left alone and we acomodate what they choose. We let them know that whatever style they prefer it won’t change anything. > meanwhile they are deducting points because I assigned a dictionary key directly vs. using the dictonary's method That sounds very unpleasant. Sorry to hear that. Interviews are a two way street. You are interviewed and at the same time you are interviewing them. I think you were right in judging them, and you dodged a bulet there. By the sound of it you are a talented, and capable developer. It might be that you can’t imagine it, but there are people who apply for developer jobs, has a really good ability to talk about the job, they seemingly have the right experience, yet somehow they can’t program even super simple tasks. Even after you give them every acommodation immaginable to humankind. If you haven’t seen this yet you won’t believe it. If you have seen it you want a filter against this particular kind of candidate. I’m not saying that this filter goes always well. Every filter ever invented had both false positives and false negatives. We might lose a briliant developer because some quirk of the task throws them. It is sad. We are trying to minimise the chances of this, but it certainly happens.

dekhn 4y ago

The predecessors to leetcode questions were being asked, for example, in PhD defense dissertations as well as some that were highly specific to the company in questions (sort 2MB of data 1MB RAM). Many of the problems are basically late-undergrad, early-graduate CS student problems.

astrange 4y ago
Do PhD defenses actually involve asking random tech questions instead of what's in the dissertation? Seems like if they're going to fail that, you already have bigger problems.
- dekhn 4y ago
  My PhD was in biophysics and the questions ranged widely outside my dissertation (in my case, you actually do a defense to proceed to work on your PhD, then write your dissertation and give a final talk; there's no way, unless your advisor rejects your dissertation, that your phd wouldn't be awarded. Other programs rear-load the process and have a real "defense" at the end, which is crazy if you think about it. At one point in my thesis defense, I derived several equations I hadn't seen before, on the fly, such as "What is the time resolved fluorescence of a fluorophore in 4-dimensional space?" and finally understanding ergodicity (https://en.wikipedia.org/wiki/Ergodicity https://en.wikipedia.org/wiki/Ergodicity). My defense wasn't about determining if I was an expert and qualified to write a dissertation in my field (my questioners already knew that), but to determine if I was a well-rounded general intelligence capable of out-of-task prediction.
  - arcanus 4y ago
    This sounds like the qualifying examination. In my phd experience in the USA we had oral qualifying examinations which involved whiteboard derivations. The thesis defense after writing was really mostly focused on probing the results in the thesis.