Hiring technical talent: An exercise in clarity, patience, and preparation
github.com
github.com
I've been to 8 hour all day interviews with a new person every hour 1-on-1. It was demoralizing and exhausting. I've been in interview cycles where I keep "moving up" to meet the next higher up person and the next higher up person to the tune of 3-5 interviews. Stop!
You can have a meaningful conversation in 2-3 hours over a couple days. Don't burn peoples time to find a unicorn. Most people are pretty competent and will rise to q challenge.
I wish a company would run an experiment where they just higher at random from a stack of team vetted resumes. I think the results would almost be the same as being super picky.
And I like the experiment idea, although I don't think anyone will ever do it without a boatload of cash to risk for no reason.
People talk a lot about the price of college not being worth it and that enrollment is declining because of the price + salaries. I think thats one part. but I'm not sure I've seen a discussion about how nearly every company out there has no confidence in a college degree.
Or in job experience, for that matter.
"You need to have 10 years experience in a technology that has only existed for 5 years, and also we assume you're a liar and discount all experience anyway."
You can verify that pretty anonymously/easily (with the interviewees permission, of course) by acting like a landlord or something, calling the previous employer and asking if $PERSON works/worked for your company and had $TITLE and did they work there $YEARS.
That should almost be the first step imo after the quick "are you a person / do you have these skills" interview which is normally reserved for an HR person who doesn't know a bit from a byte. If they picked up the phone, claimed to have some skills, a company they work/worked for genuinely seems to exist and employed them, heck hire them - I bet 9/10 it would work out just fine.
The other issue is that if we look at something likes levels.fyi [1] the roles don't always line up. Ex. Capital One's SE/Senior Associate is a similar role to both Amazon's SDE I & II. While Capital One's pay is ~137k and SDE I is ~165k / SDE II is ~237k so which do you hire the candidate at? Although it will sometimes be an "easy" choice as say Microsoft's 62 is completely within SDE II's bucket.
IMO, the probation period idea is probably the better one I've seen although it does really take people time to ramp up to all the legacy code.
[1]: https://www.levels.fyi/?compare=Capital%20One,Amazon,Microso...
That's what they claim. It seems unlikely, especially seeing some of the things they produce. ;-)
A less sarcastic point is that a company with a uniform hiring process tends to get a uniform workforce. What this means is that all employees tend to have the same strengths, and also the same weaknesses, because the hiring process is always looking for the same exact things. The result is that the team ends up not being more than the sum of all the parts but rather less than the sum of all the parts. The same strengths added together are redundant, and the same weaknesses added together create giant corporate blind spots.
When you go about trying to "minimize the bad hire", what you're really minimizing is any sort of difference or diversity among the workforce, thereby missing the forest for the trees.
We always talk about the so-called "10x engineer", but it's not clear that 2 10x engineers with the exact same skills would be better than 2 other engineers with different but complementary skills. Maybe 10x + 10x effectively adds up to much less than 20x.
If you're unlucky, you'll flounder on one of the esoteric algorithm questions that have little to no correlation to your performance at the job. In this case, you've entirely wasted your time.
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.
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.
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.
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.
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.
This is after the initial resume screen and sometimes even after they did an online leetcode style test.
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.
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.
Some took one look at it and walked out. Others would solve it in under a minute. Everyone in between.
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.
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/
Science.
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.
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.
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.
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.
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?
> 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".
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...
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.
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.
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.
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.
My experience is exactly the opposite. Most people are actually incompetent.
When a competent applicant goes through interviews with 3 companies, they probably get hired. When an incompetent applicant goes through interviews with 3 companies and doesn’t get an offer, they don’t de-materialize but instead keep applying, adding to the adversity in the pool of applicants.
It’s not that being employed makes them competent in my eyes, but rather that being competent makes them more likely to be employed.
What is the average?
My impression is that even "top" candidates take a lot of interviews, which gives them a lot of options and possibly multiple job offers that they can use to drive up the price in negotiations.
Another challenge with hiring, esp. at a startup is that many candidates who "qualify" will not be comfortable joining a startup, so you have to find both high quality and high intent people. There are some solutions that address this like https://topstartups.io/ and https://angel.co/ to some extent.
In general, there needs to be clearer signaling of preferences. Too much time wasted.
Most people cannot code.
"higher at random from a stack of team vetted resumes"
Because many offers would be declined, you would end up with mostly lemons. And the non-lemons would leave due to being surrounded by lemons.
Just a conversation is what I've always found worked. Just two people in the same business discussing some technical topic. What do you like about Rust? Why would you write this system in Java? Blah blah, and if the person doesn't actually know much they will run out of things to say. Sprinkle in some references to ordinary tools like git or gcc, and you can't avoid using industry jargon that will function like a shibboleth. If they know how to do stuff they will know the words you throw at them and throw back some of their own. If they read around their area they will know what the adjacent areas are and they'll have opinions and more keywords. It's not actually simple to make this up, for instance how would you pretend to be a surgeon or a pilot? There'd be a bunch of things you'd have to have heard of, and there isn't going to be a shortcut to knowing what they meant.
If they're a bullshitter and they somehow manage to blag themselves a job, they will get found out pretty quickly anyway, definitely before the probation period ends.
If they're someone who understands stuff, they'll appreciate talking to a technical peer and that will be part of the draw of working with me.
Yet, in every case, the interviewers put so much weight and faith in the coding challenges. I'm like really people? Can you really tell how good or bad I am in a 35 minute live coding challenge? When I'm working I sometimes make mistakes, sometimes many mistakes and then other times, I crank out a lot of decent code with few mistakes.
If someone is the head of some product at google and you want them cold email an offer you were always comfortable offering. If they accept or counter or want to talk or engage perfect you beat all the others.
It could work for targeting lower paying employees at less known places. If the person is worth at least what you are offering it's a no brainer. If a recruitor reached out to me with an offer in hand even if it was lower than my current pay I would engage knowing they are serious. When they reach out now and still require 4 rounds of interviews it becomes a farce to get someone paid for getting people into a hiring funnel. When a founder reaches out personally you listen.
I also strongly believe in the 10x programmer idea [1] and you're not even going to come across these people unless you run in the same social circles as them. Some random manager at Google is not necessarily a 10x candidate. It's very difficult to vet potential 10x candidates from just a glance because so many people exaggerate and bullshit on their resumes.
[1] https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n...
I've known enough people who've gotten where they've gotten with little technical ability that I'd be suspicious of a place that doesn't even attempt due diligence.
What I realized recently is that it’s really an attitude issue: Do you give a shit, or not?
Too much time is spent vetting the unnecessary technical.
Note this doesn't mean I actually strive to be good at those things over my job though. Just pointing it out, that's what the current technical interview process selects for.
There's a difference between someone who has 20 years of genuine experience, and someone who has 3 years of experience that they've been repeating over and over again, and unfortunately my experience is most people who've been at this job for a long time are simply those who gained a few years of experience until they got to a point of diminishing returns and then allowed their skills to stagnate to the point where a recent grad could easily ramp up to out compete them with about 1 year worth of training and investment.
What about if you gave the veteran programmer 1 year worth of training and investment?
Well, that's what everyone thinks they're testing for. The empirical evidence suggests otherwise. https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/
If what you're implying is that experience makes somebody anxious when performing under pressure, then obviously that's a rational reason to prefer those who have less experience.
I don't think experience means more anxiety though. And you don't know what the interview process of the GP is like. Why assume they are not telling the truth?
Heh, I could say the same thing. You came in later and replied to several of my comments. ;-)
> anxious when performing under pressure
I have to repeat that I'm talking about job interviews specifically, which is not the same as "performing under pressure". Job interviews are unique in many ways and very different from having a job. This ought to be psychology 101 but somehow many techies don't understand it. The pressure of an on-the-job emergency is not the same as interview pressure. They are psychologically distinct.
Anyway, I wouldn't make the general claim that experience makes somebody anxious in job interviews, but I would make the general claim that interview tests often don't actually test for the thing the designers think they do. How exactly does one test for the value of experience, for example?
One thing worth noting though: people who have been out of school and on the job for many years may have become unaccustomed to taking tests, especially if they don't interview for jobs frequently. Fresh college grads are fresh from taking tests constantly in school. So test anxiety can start to affect long experienced people just because it's no longer natural for them compared to when they were younger and in school or new on the job market.
There definitely can be and often is bias everywhere since people tend to gravitate towards others who are similar to them (i.e. young people might be biased to hire young, old people old, etc.) I can't imagine any reasonable team to take on somebody based on their CV alone though, you're almost guaranteed to hire somebody who doesn't match their own description. I've seen a couple first hand myself.
As I replied to you on the other comment, if you personally have enough options, it's actually better to let some crap companies to have subpar interview processes so that you can detect and avoid them before you take the offer. Pointing out subconscious/unintentional bias is useful though, everyone is better off.
If by CV alone you mean the mere piece of paper (or pdf document), then I agree. I definitely think candidates should be vetted. I just think that the typical way tech companies vet candidates is awful. I agree with the OP who said "don't have 500 interviews". There's a huge difference between accepting a CV without question and what tech companies effectively do now, which is completely ignore the CV and rely entirely on coding tests for evaluating candidates.
Mass interviews are unusual for many jobs outside of tech. Maybe you just interview the few top candidates. This seems like a better system, and it wastes less time for everyone, both the employer and job candidates, most of whom are necessarily rejected, if there's only 1 opening. Fewer interviews, more time vetting individual candidates. You don't have to do multiple rounds of interviews, and you don't have to do "screening". Start with your few top candidates and work your way down.
If you insist on having a coding test, do it as the last step in the hiring process, not as the first, "screening" step. Job candidates would be much less anxious about coding tests if they knew it was the last step before hiring rather than the hurdle they have to overcome to even get to talk to someone conversationally, and if they knew they weren't competing in the coding tests with a hundred other candidates. Verify, don't screen.
It's also the case that if you start with your top candidates and work your way down rather than mass interviewing, you have time to research the top candidates, such as looking at their open source if they have some. A typical excuse is "We don't have time to look at the GitHub of 500 candidates." So... don't interview 500 candidates!
Essential!
In fact, I had an interview earlier today. The two FE devs on the other end of Zoom, best I could tell, didn't look at a single repo in my CV. Instead we batted around fluff-ish questions (for the most part) instead of "In the repo in you CV why did you...?"
I was disappointed and then some.
You see and interview is like a “test” or a “pop quiz” where the day to day is more like “homework”. That is, you want to hire people who do their homework, but the only reasonable method to evaluate a candidate is to give them a test. And while a “high test score” may serve as a proxy for “completes homework”, as we all know, it’s far from perfect.
The unfortunate reality is that the best process for determining the quality of a candidate benefits neither the candidate nor the company. That is some sort of paid-trial-period-type arrangement to evaluate fit.
So we are left with these gauntlets of an interview process because it kind of splits the baby…
My honest question is, how do you run this at big tech scale? Honestly, we get dozens if not hundreds of applicants per opening. Are we going to give all of them a trial? If not, how do we choose which ones? Again we are back at square 1.
Strong disagree. I would instantly decline an interview with any company that expected me to do my interview work at home. I'm not going to work at a company that expects me to work off my scheduled hours.
Moreover, I find it quite ironic that this take-home interview is somehow supportive of "diversity and inclusion". It seems to me that the people most likely to not have the time to do their interview at home are people with families, and especially women, who often are responsible for much of the house/family work during their non-salaried hours.