I think that's fair, and why most people aren't against an hour or 90 minute tech screen where someone has to write some code. But I've had to do a 3 hour take home assignment, then an hour long tech screen solving some medium level LC problem, THEN an all day onsite doing design+multiple coding rounds.
On top of that there's the randomness factor. I know people who interviewed at FAANGs and basically had to do some easy level graph traversals and some linked list manipulations. Others get asked hard bottom up DP coding questions and need to use Prim's algorithm for MSPs like, wtf lol those are not the same thing.
It's a self-fulfilling prophesy, if you're using FizzBuzz to judge whether people are competent.
Programmers aren't stage performers, but companies treat interviews like auditions. Anyone with "performance anxiety" is assumed to be incompetent, which is silly. The tech interview/audition is unnatural and very different from normal work.
It's been shown by researchers over and over that interviews test for anxiety, not skills, but interviewers refuse to listen. https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/
Why test? Seriously, why are interviews tests?
Everyone seems very worried about incompetent job candidates, but what about incompetent colleagues and managers? We act like interviews are one-way when in fact they're two-way, and the candidate needs to decide if they actually want to work for the potential employer. Does the candidate get to test the interviewers? Nobody wants to work with incompetent colleagues, and especially not an incompetent manager, which is the worst.
There are a lot of incompetent engineering managers, and indeed I would estimate that engineering managers are more likely to be incompetent than engineers, because engineers are frequently promoted to engineering managers despite having no background or training in management.
It's ok though, I'll let the manager do a take home test in their spare time.
That's why instead of complaining that companies don't interview the way you prefer them to ("interviewers refuse to listen"), you should just let them be the "incompetent" teams that you believe them to be, so that you can tell whether they're "incompetent" and decide to take an offer from a company that does things the way you like.
Then everyone is happy!
This is a misconstrual. The point was that interviewers refuse to listen to scientific studies that show interviews test for anxiety rather than skills.
> Then everyone is happy!
Not when the whole industry cargo cults on audition-style interview tests.
Sometimes candidates prefer rigorous interviews because it means the people inside the company all made it through those same hoops.
My point was that engineers get promoted to engineering manager without any kind of "manager test", so there's no assurance of competence at all.
Also, I've heard of many cases where certain candidates are allowed to bypass the normal interview rounds, or get coached on the company's interviews, or get "softball" questions during those interviews, if the company wants to hire that person for some reason no matter what.
Moreover, there's no guarantee that the current interview process is the same as the past interview process, especially for older companies. (Think Apple, for example.) Certainly the founders of a company never went through the process, and probably the initial employees didn't either. The founding of a company is almost always "informal", and only later is a more "rigorous" process imposed on newcomers.
Of course they do - their entire experience with the company prior is the "manager test".
A company that just promotes anyone to EM that just puts their hand up, despite demonstrating their not suitable, has other problems.
This is a straw man. It doesn't happen, and nobody believes that it happens.
What does happen is that people who are good at engineering get promoted to engineering management, but writing code and managing humans are two entirely different skills.
In fact it's especially true in companies with "rigorous" entrance exams that engineers employed by the company have focused on the coding aspect heavily in the past, otherwise they wouldn't have been able to pass the exams. So their people skills would have tended to be neglected or ignored entirely.
When an engineer gets promoted to engineering manager, a significant part of the management chain has to approve of the promotion, and they have had enough interaction with the newly promoted manager that they can reasonably assess whether the promotion is suitable.
Sure, you might claim (as you seem to have, as a strawman) that before the promotion the would-be manager was merely an engineer with no management duties, but that's not exactly how things work. Sometimes it happens like you describe, but often the person being promoted gets assigned some light management or leadership duties before they take on the role officially. At any rate, the higher management already knows more about the would-be manager than any candidate you can interview in a 8 hour period.
What makes you think that people higher in the management chain are any better at managing people or even care about that aspect? Many tech companies were founded by college kids who were programmers and had no background or training in management. They were thrust into their roles by the circumstances with no preparation.
It seems like people are living in a hypothetical magical utopia in these comments instead of reality. We all know that managers are incompetent. We're experienced it. You can find endless engineers complaining about it. Why are we denying the truth here?
Your original claim is that managers are less competent because they didn't get interviewed as managers when they got promoted. The chain of replies was an attempt to refute that.
If your claim is that (for some companies) managers are less competent because that's how it has been forever, then the sample logic can apply to engineers in the company. It's not that I dispute the conclusion, but the reasoning doesn't hold because it doesn't differentiate the two cases.
My original claim was "engineers are frequently promoted to engineering managers despite having no background or training in management". This doesn't have much to do with interviews for engineering managers, though I did note sarcastically that there's no real "FizzBuzz" equivalent for managers.
Engineer to engineering manager is effectively a career change. Programming skills are different from people skills. It's important for an engineering manager to understand programming, but there's much more to the job. How many of them got management degrees in college rather the computer science degrees? How many of them were "managing since I was 13 years old" as opposed to "coding since I was 13 years old"? (You don't actually need to do either since you were 13 years old, but I think you get the rhetorical point.) Even if the "most qualified" of the current engineers get promoted to manager, that doesn't mean any of the current engineers are actually qualified to be a good manager of people rather than machines.
Science.
I've been working 10 years, can get things up and running pretty fast, learn fast, but I'm super anxious in interview (and I've done hundreds). I'm just an anxious person, so most of the time I completely freeze up. Perhaps finding a better way to interview is a better way to hire for diversity.
I think there are two camps of people: truly incompetent liars that look good on paper and people just straight up bad at interviewing who are perfectly qualified. So how do you give the latter a fighting chance?
The problem is that many (most?) interviewers have no idea how to effectively coax a candidate along. They usually sit there in silence for an awkwardly long period of time and then fail the candidate, or offer totally irrelevant hints that don't reflect how someone would actually think about the problem.
I nearly always use a glorified DFS and I find that roughly
- 50% of the candidates cannot write an iterative or recursive function (never mind actually solve the problem).
- 15% of the candidates can't figure out how to pass data recursively (i.e. a counter) and resort to a global or do it incorrectly (i.e. pass-by-value which won't work).
- 10% start with an iterative solution and change to recursive once they start having trouble (IMO good call but it is solvable iteratively).
- 10% actually come up with a completely correct answer.
~ 5% test their solution with non-provided input.
Sometimes I do wonder what prep the candidate has been given. A lot of the time they seem afraid to add a new function and instead only modify the provided template (do-able but obviously more difficult).
You're thinking that the difficulty of the question matters, but it doesn't. The difficulty is the situation. You freeze up in an interview, but then immediately after the interview you go back and solve the same problem quickly, because the anxiety is gone, and nobody is standing over you watching. But you don't get a second chance after you're rejected.
If you're not anxious, you can solve very hard problems. If you are anxious, you can't solve very easy problems. Many interviewers are astonished that candidates can't do FizzBuzz or whatever, but it's often because these interviewers don't understand fundamental human psychology, and expect everyone to be a robot with no emotions.
I tend to freeze big time in tech/mathy interviews unless I feel there is a good emotional connection with the interviewer.
Naturally, someone interviewing me who's just written a for loop in the language is going to wonder wtf I'm doing in the interview, because to them it seems like something everyone would know.
Someone who understands how to think about the problem could easily get disqualified because they don't have the little things to hand.
Ok but can you not write a pseudocode version of say fibonacci recursively? Like I don't dock people _just_ because their code doesn't compile and when I go to run it through a bunch of test cases I wrote, I'll fix compilation issues. So if you write `for(int i=0;` but the interview was in JS so `int` doesn't work I won't care.
But I guess it's easy to be impressed with the guy who also wrote the thing out in a way that compiled, even though you were not testing for that?
At some point the code deviates enough from the platonic ideal that it's no longer a perfect score. The issue is when that is?
A candidate that is able to quickly produce a correct compilable solution is more impressive than one that doesn't come up with a solution but there are a lot of shades of gray here. Often a candidate rushes to code a solution without checking (either with me or just with an example) that the solution even works. That is not more impressive to me than a candidate who "spends too long" clarifying the problem and coming up with a solid algorithm and runs out of time to code it.
You don't need a perfect score to get hired. Honestly coming up with the "most efficient" algorithm but having no clue about its performance characteristics (i.e. big-o) is going to get you a lower score than a slower algorithm but really understanding it. I do the same for correctness, if you know a part of your algorithm is "wrong" I won't dock as much because IMO you'd run that part through some test cases cause you're suspicious (i.e. should a `<` be a `<=` or even more complex logic). w.r.t. big-o, I've yet to find a candidate that coded a workable algorithm and doesn't know what it is and also couldn't deduce it when given examples (i.e. say you have 6 elements in the array, how many times do you look at their value? 36. say you have 8 elements? 64. say you have n elements? n^2).
That said, I've worked at several places and this is the first one to have a rubric for interviews. Definitely "Write down what success looks like for the exercise" is the part of the article I liked the most. And to that I look for (1) did they clarify the problem (2) can they come up with an algorithm / break the problem up into something workable (3) is what they coded what they designed (4) do they know it's runtime. (4) is pretty much directly one of the metrics so if I don't ask it I don't feel that I can justify the highest rating and from the rest I figure out what I think the other metrics should score.
You mean back up the stack via the return statement?
or via parameters in the function call?
Like I could have a recursive solution that returns the sum of the length of the sub-arrays or I could just pass a mutable object and update the length there.
Which way would depend on the exact problem (i.e. Strings would be best collected in a StringBuilder rather than concatenated but `lengthParam` would probably more clear if it returned a number instead of using the Array).
```
const lengthParam = (a,p) => {
if(Array.isArray(a)) {
for(let c of a) {
lengthParam(c,p)
}
} else {
p[0] = p[0] + 1
}
};
var b = [0]
lengthP([1,2,3,[4,5],[6]], b);
console.log(b[0]) // 6
``` ```
const lengthParam = (a) => {
let count = 0;
for(let c of a) {
if(Array.isArray(c)) {
count += lengthParam(c)
}
else {
count++;
}
}
return count;
};
```
Yet the OP's suggestion was this: "don't have 500 interviews. Have at most 2 or 3 which altogether should not take more than 2 to 3 hours of somebodys time."
In other words, the OP was recommending satisficing rather than optimizing.
Companies waste so much time on interviewing. Their own time and candidate time. Hundreds of interviews, multiple rounds, just a massive amount of time for 1 job. It certainly feels like they're trying to optimize rather than satisfice.
Most companies will also prefer the candidate who who projects tallness and youth.
Maybe these biases are something that companies need to overcome?
One can be very confident in one's work yet be anxious in a job interview.
Ex: being anxious about a job interview might really mean they get anxious in high pressure situations, talking with unfamiliar people, etc.
Depending on the role, these situations could easily be ones you encounter at work as well.
1) In an interview, you can lose the job at any moment for any little reason, because you don't even have the job yet, whereas on the job you're very unlikely to lose your job at any moment for any little reason. It typically takes gross incompetence or insubordination to get immediately fired. I've written plenty of software bugs in my career, as has everyone I suspect, but I've never been fired. I've lost plenty of jobs in interviews though.
2) The stakes are personally higher in a job interview, especially if you're currently unemployed. You can claim theoretically that the stakes are higher on the job, because "millions may be lost", but those aren't your millions, they're the company's millions. The company losing millions may suck for the company, but it doesn't necessarily mean you lose your job. Companies lose millions yet continue in business. Whereas if you don't get a job at all, you'll eventually run out of money and become homeless. That is the highest of stakes, for you.
3) If you've had a job for a while, then your coworkers already know that you're competent. They aren't suspicious of you or sitting in judgment of you, because your work has already been seen and judged. Whereas in a job interview, it is a stranger sitting in judgment of you. The issue isn't necessarily "talking to strangers" but rather you have a stranger who is wondering if you're a "faker who can't code your way out of a paper bag", and you have to prove to them otherwise in an hour.
4) In a job interview, someone is standing over you watching your every move while you work. Unless you do pair programming (which I dislike), most programmers are sitting alone at the computer most of the time, not having someone else stand over them. And even if you do sit with a coworker at the computer on the job, the process is usually collaborative rather than judgmental. You and a coworker sit together to solve a programming problem together, not so that your coworker can judge you and give you an evaluation which determines whether you get paid or not.
5) The tests given in job interviews are usually totally artificial and often have nothing to do with the job. You're just given a test — sometimes ill-defined — out of left field, at the spur of the moment, and you have to solve it in a few minutes, because the job interviewer can't sit and wait for you to take however long you need. People who interview a lot, or who are coached in interviewing techniques, apparently learn that there are tricks to interviewing, and you can ask the interviewer multiple questions to clarify and talk through the process, but someone who doesn't interview much doesn't know this. You rarely get such artificial, out of left field problems at work that need immediate solution. At work, you have meetings, discuss the product, discuss what's needed, before you work on things. Or if there's a work "crisis", the crisis has to do with your company's codebase, which you're already familiar with and may have written yourself!
I could go on and on and on, but hopefully that's enough to show that the pressures of job interviews are unique and not the same as work pressures, no matter how bad the "emergency" at work.
One more thing about different pressures and psychology: It's well known that many people have a specific fear speaking in front of groups of people. So why is the notion so strange that people have a specific fear of job interviews. I have little doubt that there are firefighters, who rush into burning buildings for a living, who would feel sick at the idea of giving a speech in front of a thousand people in a non-burning building. Anxieties are not all the same, they're often very specific.
It's sad to me, though not surprising, that many hard techies don't understand human psychology and have a hard time empathizing.
I do also think that for most roles an interview situation is extremely different to what your job is going to be like.
After a while it got to the point where I’d walk in give an easy five minute coding exercise walk out and give a thumbs up or down. They could use any language editor or tool they wanted. We even provided a few alternatives they could pick from in case they just had a weird mental block on our preferred one.
Others would make sure that they weren’t too insane personality wise.
Other team members were constantly shocked by candidates that were verbally great but couldn’t do deal with hashes or arrays at all.
Quick questions like this always throw me. I don't think about programming in a way where free floating questions make much sense to me initially.
A a b b c c c c d e
Give me a function that given a number returns the letters that have that many in it. You have 60 minutes. Any language.
letters = %w(A a b b c c c c d e)
letter_map = Hash.new(0)
letters.each do |letter|
letter_map[letter] += 1
end
def print_count(map)
map.each do |key, value|
puts "\"#{key}\": #{value}"
end
end
def match_count(map, count)
map.select { |key, value| value == count }.keys
end
print_count(letter_map)
match_count(letter_map, 4)https://www.penny-arcade.com/comic/2008/02/13/professor-layt...
Why are you always asking me to rediscover and reimplement the Fibonacci sequence when none of us give a fuck about it? This whole thing's insane, what have I become.
This is after the initial resume screen and sometimes even after they did an online leetcode style test.
Some took one look at it and walked out. Others would solve it in under a minute. Everyone in between.
There are lots and lots of big company jobs where you can skate by writing ~100 lines of code a week (or less!) all inside the mandated Big Company In-House Framework. In fact your boss demands that you work this way.
I mean, that was totally me for years, so I’m not judging too harshly.
I’ll still google “how 2 for loop” sometimes.
How would anyone know? Once a candidate fails the screen, the company rejects and never gives a second thought to the candidate again.
Does any company do follow-up to see what happened in the future to rejected candidates? I've never heard of that happening.
The coding screens are just assumed to be infallible, so the candidate must have been a fraud. It's unthinkable that the screening tests themselves are wrong, because then the whole hiring process is misguided.
How would you possibly know they can't code basic things?
Did you hire them and over many months it turned out they actually can't code a basic thing?
Or did you ask some arbitrary algorith memorization question, completely unrelated to the actual job so of course it's not something they do day to day, and they didn't give the perfect performance balanced just right between pretending they haven't seen it before and acting like they're deriving a decade of CS research on the whiteboard in 45 minutes out of the blue?
I'm betting on the second.
But taking a step back and thinking about it: is it really possible for someone to have been writing production code for years and not know how to iterate through an array looking for smallest element?
I firmly assert that no, it is not possible. This shouldn't be controversial. Seriously, it's not possible to not know how to do that for anyone who has written more than a few days of casual code, let alone years of professional production code.
And yet the interview makes it seem like they can't? Which I'll also believe.
So what's going on?
What's going on is that the interviews are measuring something entirely different, not programming skill.
Which means the interview technique is wrong because it isn't measuring the skills, it's just measuring tolerance to the extreme stress of the interview. Which many conflict-avoiding introvert programmer types are very bad at, even though they are excellent at programming.
But in the end I have literally sat in an interview with someone who has professional experience and who couldn't write a function to find the smallest element in an array without significant help from me. That's just a fact. I'm not sure what the theoretical basis of that was. I'm not sure how the person could have experience and not be able to complete such a simple thing. All I know is that it literally happened.
Trying to argue from some theoretical principles that it couldn't have happened doesn't make much sense to me given that, like, it actually happened.
I believe it actually happened, in the context of the extreme stress of an interview.
Do you think that same person back at their desk at work, without anyone breathing down their neck, can't write a loop?
But you are presumably trying to hire people to sit at their desk and write code, so it is the latter skill that is important, not the former.
The only case where programming under extreme stress might be a relevant quality is in a workspace where you routinely have a VP screaming at you to fix a customer bug right now or you're fired. And there's no reason to tolerate such a toxic workplace, so there's no reason to use such a terrible interview strategy.
I don't know which sadist in HR or management came up with the idea of doing 6-8 mandatory interviews for every candidate and then telling them, "Oh sorry, you're not selected because you didn't do your first (or second) round well". This is an utter waste of time for the interviewers and especially the candidate.
I am almost convinced that the market has made it so people have to lie on their CVs to get through the HR filters to even have a shot.
I’ve only ever interviewed people for “normal” level jobs, and I have never once seen someone lie on their resume or even act like they knew something they didn’t.
I think big companies either make up this problem, or they created this environment for themselves.
I have a hard time believing they exist, excepting blatant fraud.
Someone who has a resume with accomplishments means that person has a proven record of getting the job done. Not being able to do a FAANG FizzBuzz has no relationship to their ability to get the job done.
You never hired these people so you have no idea how they would do either.
Have you ever heard of someone hiring a surgeon by giving them an over ripe orange and a plastic knife and asking them to cut out every 2nd segment without getting any juice on the table?
This sounds good, but experience has taught me it’s just not true.
It’s so easy to claim credit for accomplishments where other people did 90% of the work. And in a big company it takes about 2 years for a bad hire to get pushed out, if they ever are.
Two wrongs don't make a right. I wish that engineers would spend half as much time trying to correct the organizational dysfunction of their companies as they do on leetcode and the like.
The tech industry that likes to brag about "innovation" and "disruption" seems very conservative and resistant to change as far as hiring is concerned. Everyone seems complacent about that and stuck in the status quo. Then they complain about a talent shortage...
> then sitting down with them and they can't even come up with a for loop
If someone has been writing succesful production code in C++ for ten years, there is zero possibility they can't write a for loop. I hope you do realize that is not actually possible.
What is extremely likely, is that they get subjected to a random algorithm memorization puzzle question for something they've never seen before under the extreme stress of an interview and then the interviewer extrapolates from that to assume "they can't write a for loop".
I would love a widely recognized and rigorous credential that I could study for and work towards if it meant I never had to do another technical interview again. They can be less rigorous than surgeons since we're not saving lives, obviously.
Yet software engineers with 7 years of experience are still assumed to be fakers.
The reputable institution is called their previous employer(s). If someone has worked for a recognized company for 7 years writing production code, that's the same as the surgeon having done those 7 years in a reputable hospital.
Have you ever interviewed someone whose resume looked good but who couldn't code basic things? The kind of candidate FizzBuzz was invented for?
I interview at a FAANG and encounter these candidates all the time. I feel the approach of "if their resume looks good they must be fine technically" makes sense until precisely the point when you interview one of these candidates.