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?
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.
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.
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.
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.
Yes.
> I'm disputing is your assertion that there is a correlation between doing the contrived problems under unrealistic conditions and future job performance.
You are projecting something here. You are saying, without any supporting evidence, that the problems are contrived. They are not. They are really the core of what me and my coworkers do day in and day out.
You are also saying that the conditions are unrealistic. What makes you think that?
You are right though I have no evidence they are contrived other than your example problem. The unrealistic working conditions though is indisputable, do you typically relay your google search's for syntax through your boss? Do you often work under extreme time pressure on problems you have never seen before? Perhaps you do, but I can tell you with certainty that it's not the norm in the industry to work in that way.
Indeed, this is a holy grail of the applicant funnel. If a tech-for-interviewing company comes up with a better way to remove the worst 50-ish% of applicants efficiently, they’ll have no worries about their future. (The overall applicant pool is significantly adversely skilled as compared to the have been or will be quickly hired pool.)
# 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]}
""")
$ 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: 17One 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.
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.
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.
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.
Again, no different than having an Ivy League education. There are big advantages to scope/reach/opportunities in the industry.
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).
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.
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.