6 ms·

Perhaps there's another collectively shared work experience that also created leetcode style interviews. That is dealing with someone who has a degree, can spea

by 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.
  - drugstorecowboy 4y ago
    I can certainly understand that there are unqualified people who apply, what I'm disputing is your assertion that there is a correlation between doing the contrived problems under unrealistic conditions and future job performance. It sounds like your goal is just to filter out the absolute worst of the worst, and I'm sure its effective at that, but I believe you might be filtering out more of the top end than you realize.
    - 4y ago
hereyougo 4y ago
Here you go # 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. from collections import Counter import random r = random.Random() songs = range(1,900) unplayed = set(songs) # 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. counter = Counter() firstrepeat = None totalplays = 0 while unplayed: song = r.choice(songs) unplayed -= set([song]) if firstrepeat is None and song in counter: firstrepeat = len(counter) counter[song] += 1 totalplays += 1 print(f""" Number of songs played before a repeat: {firstrepeat} Total number songs played: {totalplays} Most common song: {counter.most_common()[0][0]} How many times has the most common song was played: {counter.most_common()[0][1]} """) Sample run $ python3 foo.py Number of songs played before a repeat: 50 Total number songs played: 7263 Most common song: 375 How many times has the most common song was played: 17
- fuzzythinker 4y ago
  Nice. I would add % of it played vs. median and how many std.deviations from it.
- visarga 4y ago
  I'm wondering why would the music player implement sampling with replacement and not without replacement? Sampling without replacement would shuffle the list and then play the tracks in shuffled order, no repeats until all songs are played once.
  - jboy55 4y ago
    This is what I was thinking, as I was driving in, and heard the same song. It was an iPhone, and it was my impression that this is how the iPhone worked. Now, my iPhone did something else weird, it randomly dropped songs from being downloaded, so songs 'disappeared'. One other thing, I just got a new car, and this was the first time I was using 'next' using bluetooth. So, as I was driving in, I was in my head trying to figure out whether the phone now only had 100 songs downloaded, or whether this bluetooth 'next' function on shuffle was picking a random song from the list, rather than 'next' on a shuffled list.
cmiles74 4y ago
This fear of hiring inept people kind of surprises me. Can't they just let people go who interview very well but are poor performers on the job? If they don't care to follow up on the performance of new hires, I have to wonder if it really matters one way or the other. I'm outside any major metro area, when we've needed to hire there haven only been a handful of people responding. When people come in for an interview it's been pretty easy to tell if they really can't code at all without making them actually code. I haven't found this to be challenging. I suspect the issue is interviewing a large number of people in a short period of time. If you don't have 45 minutes or so to spend on each person, using automated leetcode style problems probably starts to seem like a pretty attractive way to weed people out. Lastly, usually one or two people from my team would take part in interviews. If there aren't any developers available at interview time (i.e., it's a manager and a someone from HR), I can start to see how people without any real coding experience can make it through the process. Again, this is probably a place where automated testing looks like a reasonable solution.
- sokoloff 4y ago
  > Can't they just let people go who interview very well but are poor performers on the job? Eventually, yes. But it takes time for them to start, time and money to onboard them, evaluate how they’re ramping up, then if not acceptable, to follow whatever performance management process is indicated by the company and local law, then transition whatever work they were doing. This could be several months and tens of thousands of dollars just to get back to a worse state than when you walked into interview that candidate. Interviewing even slightly better than last year can pay large dividends.
akhmatova 4y ago
I will google it for you if you don't remember the syntax. You might as well just stand behind them and breath down their neck for added effect. Seriously, that's way too claustrophobic, and not to mention a huge practical annoyance -- for the added latency of having to ask you to google stuff for them and then give you the result somehow, instead of just letting them do it themselves, when all they want to do is get past this trite exercise and start having a real conversation.

by jboy55 4y ago

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.
- drugstorecowboy 4y ago
  I can certainly understand that there are unqualified people who apply, what I'm disputing is your assertion that there is a correlation between doing the contrived problems under unrealistic conditions and future job performance. It sounds like your goal is just to filter out the absolute worst of the worst, and I'm sure its effective at that, but I believe you might be filtering out more of the top end than you realize.
  - 4y ago

hereyougo 4y ago

Here you go # 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. from collections import Counter import random r = random.Random() songs = range(1,900) unplayed = set(songs) # 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. counter = Counter() firstrepeat = None totalplays = 0 while unplayed: song = r.choice(songs) unplayed -= set([song]) if firstrepeat is None and song in counter: firstrepeat = len(counter) counter[song] += 1 totalplays += 1 print(f""" Number of songs played before a repeat: {firstrepeat} Total number songs played: {totalplays} Most common song: {counter.most_common()[0][0]} How many times has the most common song was played: {counter.most_common()[0][1]} """) Sample run $ python3 foo.py Number of songs played before a repeat: 50 Total number songs played: 7263 Most common song: 375 How many times has the most common song was played: 17

fuzzythinker 4y ago
Nice. I would add % of it played vs. median and how many std.deviations from it.
visarga 4y ago
I'm wondering why would the music player implement sampling with replacement and not without replacement? Sampling without replacement would shuffle the list and then play the tracks in shuffled order, no repeats until all songs are played once.
- jboy55 4y ago
  This is what I was thinking, as I was driving in, and heard the same song. It was an iPhone, and it was my impression that this is how the iPhone worked. Now, my iPhone did something else weird, it randomly dropped songs from being downloaded, so songs 'disappeared'. One other thing, I just got a new car, and this was the first time I was using 'next' using bluetooth. So, as I was driving in, I was in my head trying to figure out whether the phone now only had 100 songs downloaded, or whether this bluetooth 'next' function on shuffle was picking a random song from the list, rather than 'next' on a shuffled list.

cmiles74 4y ago

This fear of hiring inept people kind of surprises me. Can't they just let people go who interview very well but are poor performers on the job? If they don't care to follow up on the performance of new hires, I have to wonder if it really matters one way or the other. I'm outside any major metro area, when we've needed to hire there haven only been a handful of people responding. When people come in for an interview it's been pretty easy to tell if they really can't code at all without making them actually code. I haven't found this to be challenging. I suspect the issue is interviewing a large number of people in a short period of time. If you don't have 45 minutes or so to spend on each person, using automated leetcode style problems probably starts to seem like a pretty attractive way to weed people out. Lastly, usually one or two people from my team would take part in interviews. If there aren't any developers available at interview time (i.e., it's a manager and a someone from HR), I can start to see how people without any real coding experience can make it through the process. Again, this is probably a place where automated testing looks like a reasonable solution.

sokoloff 4y ago
> Can't they just let people go who interview very well but are poor performers on the job? Eventually, yes. But it takes time for them to start, time and money to onboard them, evaluate how they’re ramping up, then if not acceptable, to follow whatever performance management process is indicated by the company and local law, then transition whatever work they were doing. This could be several months and tens of thousands of dollars just to get back to a worse state than when you walked into interview that candidate. Interviewing even slightly better than last year can pay large dividends.

akhmatova 4y ago

I will google it for you if you don't remember the syntax. You might as well just stand behind them and breath down their neck for added effect. Seriously, that's way too claustrophobic, and not to mention a huge practical annoyance -- for the added latency of having to ask you to google stuff for them and then give you the result somehow, instead of just letting them do it themselves, when all they want to do is get past this trite exercise and start having a real conversation.