We can't judge another programmer's abilities in a 60 minute interview(linkedin.com)
linkedin.com
We can't judge another programmer's abilities in a 60 minute interview
https://www.linkedin.com/feed/update/urn:li:activity:6528766848526278657
155 comments
This is all pretty hyperbolic. And NO-ONE applies to you too, you are vested in the belief your candidate is a genius, especially when you pulled strings to get him in.
As long as you are thinking in absolute truths, you are missing the point imo. There is a set of good candidates for a given moment, and context, and the idea is to increase the percentage picked from that pool. The cost of missing someone from the good pool is also far smaller than picking a bad candidate.
Anecdotes of rock stars, and 10x programmers just further muddy the waters. Because those guys are the 0.1% and will be fine either way.
As long as you are thinking in absolute truths, you are missing the point imo. There is a set of good candidates for a given moment, and context, and the idea is to increase the percentage picked from that pool. The cost of missing someone from the good pool is also far smaller than picking a bad candidate.
Anecdotes of rock stars, and 10x programmers just further muddy the waters. Because those guys are the 0.1% and will be fine either way.
> NO-ONE - no-one ever thinks they make the wrong call when they reject a candidate - including you.
I disagree. Maybe not immediately, but I’ve definitely picked the wrong candidate when I had two other better candidates in hindsight.
I disagree. Maybe not immediately, but I’ve definitely picked the wrong candidate when I had two other better candidates in hindsight.
Why did they reject him the first time around?
As a recruiter what percentage of the time are you throwing candidates at jobs to see what sticks?
As a recruiter what percentage of the time are you throwing candidates at jobs to see what sticks?
>> Why did they reject him the first time around?
Because most people do a really bad job at technical interviewing and selection - there's so much to say about why it would take a book to explain it all. BUT importantly - everyone thinks they do a great job at interviewing and selection.
>> As a recruiter what percentage of the time are you throwing candidates at jobs to see what sticks?
I'm not sure I understand the question. Is it saying "recruiters send any old person for a job in the random hope they might get it, how often do you do that?".
I don't do that.
I try to find the right person for the job, I look for people who are smart and get stuff done and I send people who I think are going to contribute something meaningful to a company. I use my technical expertise to try to understand the candidates level of technical experience, and I articulate the strengths and weaknesses of the candidate to the employer.
Because most people do a really bad job at technical interviewing and selection - there's so much to say about why it would take a book to explain it all. BUT importantly - everyone thinks they do a great job at interviewing and selection.
>> As a recruiter what percentage of the time are you throwing candidates at jobs to see what sticks?
I'm not sure I understand the question. Is it saying "recruiters send any old person for a job in the random hope they might get it, how often do you do that?".
I don't do that.
I try to find the right person for the job, I look for people who are smart and get stuff done and I send people who I think are going to contribute something meaningful to a company. I use my technical expertise to try to understand the candidates level of technical experience, and I articulate the strengths and weaknesses of the candidate to the employer.
Thanks for answering. I guess I was asking what was it about this super candidate that they miss or got wrong?
I have been on the receiving end of a lot of bad recruiters. I have found that my needs were ignored and anyone who could fog a mirror was thrown my way has made me somewhat cynical of recruiters. If you are doing the right thing then this is fantastic. I wish people like you weren’t so rare.
I have been on the receiving end of a lot of bad recruiters. I have found that my needs were ignored and anyone who could fog a mirror was thrown my way has made me somewhat cynical of recruiters. If you are doing the right thing then this is fantastic. I wish people like you weren’t so rare.
In your opinion, do you think that the hiring manager rejected the applicant because that hiring manager thought the applicant was too good? As in, that the applicant was a possible threat in the company hierarchy to the hiring manager?
Asking because I've seen that one play out a fair few times.
Asking because I've seen that one play out a fair few times.
>> In your opinion, do you think that the hiring manager rejected the applicant because that hiring manager thought the applicant was too good?
Not in this case, but I definitely think you are correct, that some people don't want to hire someone who might be smarter than them and therefore be a threat to their position in the hierarchy/sense of belonging/job security.
Not in this case, but I definitely think you are correct, that some people don't want to hire someone who might be smarter than them and therefore be a threat to their position in the hierarchy/sense of belonging/job security.
> NO-ONE - no-one ever thinks they make the wrong call when they reject a candidate - including you.
At least for me, a "no hire" does't mean that I'm convinced the developer wouldn't be a good fit. In fact, I'm pretty sure my team is likely passing on some good developers that just don't look that way given the limited time and options we have to evaluate their skills and overall "fit."
But, we try to follow Joel Spolsky's suggestion of turning any "maybe" into a "no", so this reality is an accepted trade-off in the model that informs how we hire.
At least for me, a "no hire" does't mean that I'm convinced the developer wouldn't be a good fit. In fact, I'm pretty sure my team is likely passing on some good developers that just don't look that way given the limited time and options we have to evaluate their skills and overall "fit."
But, we try to follow Joel Spolsky's suggestion of turning any "maybe" into a "no", so this reality is an accepted trade-off in the model that informs how we hire.
I’ve seen this so many times as well where candidates under sell themselves or key accomplishments never get brought up. Even Elon Musk in the most recent Autonomy day had to say to Karparthy “introduce yourself and don’t be bashful.” Even then, I’ve noticed, I’ve noticed that people don’t “hear” things until a second or third conversation. The idea that you can absolutely hear everything a candidate has to say in 60 minutes is just unreasonable. At the same time, I think you did the right thing: you helped your client make a better decision but not letting them rely on a first look exclusively.
You assume that the reason the guy did not get the job is that candidate undersold themselves.
It is mostly the responsibility of the technical interviewers to determine if the candidate is suitable.
It is mostly the responsibility of the technical interviewers to determine if the candidate is suitable.
[deleted]
Sounds like this guy was overqualified for the position. (Probably asked too much money, too.)
The fact that the candidate went on to a non-programming position confirms.
In any case, it was the strings you pulled that let the guy get promoted.
The fact that the candidate went on to a non-programming position confirms.
In any case, it was the strings you pulled that let the guy get promoted.
All your conclusions are wrong.
He wasn't asking too much money.
He wasn't overqualified.
He took the job and did programming.
Why you assume lead architect means not programming is not something I know.
I didn't pull strings to get him promoted.
But all your conclusions illustrate why technical recruiting is so broken - no-one ever has any problem justifying outcomes after the fact and making up stories to match their own reality.
He wasn't asking too much money.
He wasn't overqualified.
He took the job and did programming.
Why you assume lead architect means not programming is not something I know.
I didn't pull strings to get him promoted.
But all your conclusions illustrate why technical recruiting is so broken - no-one ever has any problem justifying outcomes after the fact and making up stories to match their own reality.
Post author here:
My new company helps companies fill contract software positions. We're a lot like a recruiting or staffing agency, but trying to do it in a new, less spammy way. It's been REALLY frustrating working with hiring managers. I used to be one of these frustrating hiring managers so I guess I had it coming.
I had a hiring manager tell me that he can tell in the first 15 min of an interview if someone is a great engineer or not. I remember thinking the same thing. I felt like I had this special intuition that I had developed over the years. That's just total BS. There is NO WAY you can know that and you don't have a "special gift".
I don't have a great solution yet, but for senior engineers I've come to trust previous work experience the candidate has much more than my gut, my culture fit questions and my stupid coding questions. We had a hiring manager that was looking for a strong back end engineer turn down the engineer that built the search backend for yelp because he didn't like his answer to "how would you program the code in an elevator."
So my new company Facet (www.facetdev.com) is basically built around helping senior engineers, with strong experience building products at scale, find contract work.
My new company helps companies fill contract software positions. We're a lot like a recruiting or staffing agency, but trying to do it in a new, less spammy way. It's been REALLY frustrating working with hiring managers. I used to be one of these frustrating hiring managers so I guess I had it coming.
I had a hiring manager tell me that he can tell in the first 15 min of an interview if someone is a great engineer or not. I remember thinking the same thing. I felt like I had this special intuition that I had developed over the years. That's just total BS. There is NO WAY you can know that and you don't have a "special gift".
I don't have a great solution yet, but for senior engineers I've come to trust previous work experience the candidate has much more than my gut, my culture fit questions and my stupid coding questions. We had a hiring manager that was looking for a strong back end engineer turn down the engineer that built the search backend for yelp because he didn't like his answer to "how would you program the code in an elevator."
So my new company Facet (www.facetdev.com) is basically built around helping senior engineers, with strong experience building products at scale, find contract work.
Are you selling the technology here? I honestly thought that since you are dealing with humans dealing themselves with other humans, you ought to have some of those humans specialist (sociologist, psychologist and other humans specialist) to help you help them.
I have written in what I hope will come across a humorous, but this is extremely reminiscent of the early days of the 5 Eyes where the US was trying to sell this to its close western allies as a way to replace investment in human resources going forward by buying into technology. And surely the technology side is tremendous these days, but it hasn't eliminated the need for human resources. We are dealing with human through those systems (technological or organisational).
I have written in what I hope will come across a humorous, but this is extremely reminiscent of the early days of the 5 Eyes where the US was trying to sell this to its close western allies as a way to replace investment in human resources going forward by buying into technology. And surely the technology side is tremendous these days, but it hasn't eliminated the need for human resources. We are dealing with human through those systems (technological or organisational).
Also, for the curious, the post has had nearly 1.5M views so far. This is the first time I've ever experienced anything I've posted go viral. It's been interesting to watch the acceleration over the past few days.
I agree, a 60 minute judgment may just be a random gut feeling, but...
Your new service offers to connect ex-Google, ex-Facebook, ex-YadaYada with work. It’s all pedigree. Pedigree in my face, on page and in the website title tag.
And... I’m none of those.
So... I personally prefer a world in which I have a chance to be misjudged to a world where I have no chance at all. Maybe it’s just me though...
I think you got the observation right. The solution, no so much so.
Your new service offers to connect ex-Google, ex-Facebook, ex-YadaYada with work. It’s all pedigree. Pedigree in my face, on page and in the website title tag.
And... I’m none of those.
So... I personally prefer a world in which I have a chance to be misjudged to a world where I have no chance at all. Maybe it’s just me though...
I think you got the observation right. The solution, no so much so.
Yeah, we're not trying to solve the hiring/interviewing problem yet. We've completely punted on that by only working with people that have a very specific type of experience. We know that leaves out a HUGE number of excellent engineers.
Right now we are focusing on a small niche to try and build a sustainable business. Then we'll have the resources and impact to solve the broader problem.
Right now we are focusing on a small niche to try and build a sustainable business. Then we'll have the resources and impact to solve the broader problem.
What problem did you attempt to solve? You are essentially offloading the vetting problem to all the companies who's former employees you work with. The only value I can see that you create is in liquidity in the market.
Sure, there's some benefit to solving market inefficiencies and making some money along the way, but don't pretend for a second that this isn't just another recruiting firm using pedigree as a proxy for actual skills.
Sure, there's some benefit to solving market inefficiencies and making some money along the way, but don't pretend for a second that this isn't just another recruiting firm using pedigree as a proxy for actual skills.
I had written basically this same response fearing I was being overly judgemental before seeing your response but my gut was the same.
The posts read like sales pitches for someone solving a problem of making money for themselves by limiting their portfolio to candidates for whom $company had done the hard work of vetting by having previously hired.
Click-bait is a generous summation, I feel.
The posts read like sales pitches for someone solving a problem of making money for themselves by limiting their portfolio to candidates for whom $company had done the hard work of vetting by having previously hired.
Click-bait is a generous summation, I feel.
Some people find our service valuable. There are devs that would prefer to be freelance but don't want to spend the time doing sales to make sure they have consistent work.
> What problem did you attempt to solve?
Two problems.
1. Finding a senior freelancer is hard. I've been unhappy with sites like Toptal and Upwork. 2. Being a senior freelancer is hard. Finding work, getting paid. We offer services for freelancers to take care of that.
Some people find it valuable.
Two problems.
1. Finding a senior freelancer is hard. I've been unhappy with sites like Toptal and Upwork. 2. Being a senior freelancer is hard. Finding work, getting paid. We offer services for freelancers to take care of that.
Some people find it valuable.
But someone hiring doesn't need you to use "has worked at a FAANG or similar" as a filtering mechanism, so that's not the value you can provide. Perhaps they'd have trouble finding someone who "has worked at a FAANG or similar" for a contract job without you, and that's it.
Senior software engineers are reluctant to leave their safe FTE jobs to go contract because they don't want to do sales, chase payments, manage a business, etc. We help contractors with that. Once a contractor goes full-time contract through Facet, we try to keep them always busy with as much work as they want. So yeah, it's hard to hire those types of devs on a single contract. It's also hard to find them on sites like Toptal or Upwork because they get priced out of the market.
That makes sense, it just means the brief post you linked here isn't really relevant to your firm's actual competencies and value provided, which are not really about filtering programmer abilities.
Thank you for this. You have the right problem statement. I hope you can solve it! I suspect it will be a tough battle, but it sounds like you have no illusions about that. Best of luck to you!
[deleted]
I read this in your HN profile: "Facet is a marketplace for hiring ex-Google, Netflix, Facebook, etc devs." Doesn't that mean you're excluding everyone who wasn't chosen by the very hiring managers you're criticizing, at an elite list of companies?
Obviously interviewing isn't 100% accurate. Almost nothing is. You definitely can't tell in 60 minutes whether someone will be a success at your company.
But you often can tell, with very very nearly 100% confidence if someone will not be a success. And that is the purpose of the interview. To filter out the "definitely not"s — the programmers who can't write fizzbuzz. And yes, I have seen plenty of these.
And interview is not the be-all and end-all of recruiting: of course it isn't. But I'm seeing a pendulum swinging a long way in the other direction now, and a lot of people talking as though interviews are worthless. They're really not.
But you often can tell, with very very nearly 100% confidence if someone will not be a success. And that is the purpose of the interview. To filter out the "definitely not"s — the programmers who can't write fizzbuzz. And yes, I have seen plenty of these.
And interview is not the be-all and end-all of recruiting: of course it isn't. But I'm seeing a pendulum swinging a long way in the other direction now, and a lot of people talking as though interviews are worthless. They're really not.
And yet the discussions on the candidate post-hiring interviews mostly revolves around whether they confirm to the company/tech/what-have-you 'culture' which, imo, is simply a euphemism for ageism, in-group bias, prejudice, hubris, and one-upmanship more often than not. The world would be a better place if people started accepting the fact for what it is: There wouldn't be so much despair around the tech interview process if not everything was broken, surely?
Refs:
https://news.ycombinator.com/item?id=9166501 (On Secretly Terrible Engineers).
https://news.ycombinator.com/item?id=19541617 (How Not to Hire a Software Engineer).
Refs:
https://news.ycombinator.com/item?id=9166501 (On Secretly Terrible Engineers).
https://news.ycombinator.com/item?id=19541617 (How Not to Hire a Software Engineer).
And yet when a company tries to reduce a candidate to a consistent set of objective criteria as best it can--meaning, the ability to understand programming problems and solve them in a structured interview--people get upset because it doesn't account for the "big picture" of the candidate and unfairly excludes people who'd otherwise be a great fit.
The reality is that any interview procedure is bound to have some false positives and some false negatives, and there will always be people who see themselves as false negatives (correctly and incorrectly) who'll complain loudly about any procedure.
The reality is that any interview procedure is bound to have some false positives and some false negatives, and there will always be people who see themselves as false negatives (correctly and incorrectly) who'll complain loudly about any procedure.
If it were only true or false negatives complaining, that would be one thing. But lots of the complaining also comes from true positives. I've gotten every tech job I've interviewed for since college, and have usually been quite successful in the companies I've worked for. I think all of those interviews were evaluating me on the wrong metric. They evaluated something I also happen to be relatively good at - I have a CS background and I'm ok at contrived little programming problems - but I believe the companies just got lucky that I'm actually even better at the kinds of things that are important in my work - problem analysis, solution design, consensus seeking, teamwork, communication, writing, debugging, research, detail orientation, automation, process definition, etc. etc. etc. - none of which has any real overlap with writing little code snippets.
All of those things, though, are inherently hard to test in a way that's fair, representative, and not easily cheated. Anyone who had a reproducible, consistent way to evaluate which candidates are good at those things would be able to make a whole lot of money.
I don't disagree, but that also doesn't mean coding interviews like we do them now are the best alternative.
Heh. The last couple time I've seen a candidate rejected for "poor culture fit", it was because the candidate themselves demonstrated ageism or racism.
Racism as in speaking up against reverse racism?
Unfortunately, no. Explicit racism: making negative assertions about specific races. During the interview. :|
First I was going to express disbelief that any candidate would think that was OK to do. But somebody could be a racist trying to find a racist employer that accepts that kind of talk. Weird & wrong, but rational, and probably something they do all the time in other parts of their life.
Then I had the outlandish idea that the local employment opportunity office is getting especially gung-ho and sending decoys through the pipeline. That would be a fun job. Basically getting paid to be a shock comedian who bombs every time.
Then I had the outlandish idea that the local employment opportunity office is getting especially gung-ho and sending decoys through the pipeline. That would be a fun job. Basically getting paid to be a shock comedian who bombs every time.
> company/tech/what-have-you 'culture' which, imo, is simply a euphemism for ageism, in-group bias, prejudice, hubris, and one-upmanship more often than not.
In my experience working with a couple of wildly different companies who prided themselves on "culture", it's largely just "don't be a dick".
It's still important though.
In my experience working with a couple of wildly different companies who prided themselves on "culture", it's largely just "don't be a dick".
It's still important though.
How would you know if you failed in identifying someone as not being able? You wouldn't hire them so you wouldn't know when you were wrong
Hiring a bad person is worse than passing on a good person. You have to optimize your interview process to account for this, and that means you will almost certainly pass on some good candidates.
Yes, to some extent you have to accept that you could end up passing on some candidates whom could have turned out to be good employees. Couple thoughts though:
1.) It's still only in hindsight that you could say something like that (ie. "wow that person really did turn out good")
2.) If you're still hiring good employees at a decent rate, does it matter? Short of being 100% efficient (which is an inappropriate goal anyways), you'd only need to address this if you were somehow not hiring anyone or hiring way below industry pace
> You definitely can't tell in 60 minutes whether someone will be a success at your company.
> But you often can tell, with very very nearly 100% confidence if someone will not be a success.
These two statements are at odds. If you can tell one you can tell the inverse.
The truth is you can't tell in either direction from a single 60 minute interview. Your "very very nearly 100% confidence" rate is outlandishly wrong.
> But you often can tell, with very very nearly 100% confidence if someone will not be a success.
These two statements are at odds. If you can tell one you can tell the inverse.
The truth is you can't tell in either direction from a single 60 minute interview. Your "very very nearly 100% confidence" rate is outlandishly wrong.
> These two statements are at odds. If you can tell one you can tell the inverse.
Only if you treat candidate aptitude as binary. Really, aptitude is probably better thought of as a spectrum, and if that's the case then it is not a contradiction to say that you know that (1) someone wouldn't be an obviously bad employee and (2) that same candidate might only be a meh employee.
Only if you treat candidate aptitude as binary. Really, aptitude is probably better thought of as a spectrum, and if that's the case then it is not a contradiction to say that you know that (1) someone wouldn't be an obviously bad employee and (2) that same candidate might only be a meh employee.
Exactly. You want to know, roughly, something like "is this candidate in the top 10%?". You might conclude "She seems to be at about the 85th percentile, give or take 10%", so she might be in the top 10% of might not. But you might conclude "He seems to be at about te 50th percentile, give or take 10%", in which case you're not interested. There is a fundamental asymmetry here.
It's hilarious to me that your name is BinaryIdiot and your post is a false dichotomy.
Except for extreme outliers it is not clear that it's possible to tell with much confidence in either case. Why do you think it's possible to have such high confidence in one case but not the other?
Because if you can't FizzBuzz, you definitely aren't going to be able to pick up the codebase in a satisfactorily short amount of time.
If you come in in gross clothes and swear, you're not going to fit the company culture.
If you're rude to your interviewer, you're not likely to be less rude to your other coworkers.
etc.
If you come in in gross clothes and swear, you're not going to fit the company culture.
If you're rude to your interviewer, you're not likely to be less rude to your other coworkers.
etc.
I cannot recall the last time I interviewed someone for a position other than intern who could not at least muddle through a FizzBuzz problem. I'm talking hundreds of candidates. The likelihood of a "lucky streak" as long as that if "can't FizzBuzz" is common (i.e. not an outlier) is small.
Usually when I dig into a person claiming "can't FizzBuzz is common" the result is I find what they're calling "FizzBuzz" is nothing of the sort, but is actually a more tricky data structures or algorithms problem.
Usually when I dig into a person claiming "can't FizzBuzz is common" the result is I find what they're calling "FizzBuzz" is nothing of the sort, but is actually a more tricky data structures or algorithms problem.
I have to assume you are doing some kind of very strict resume screening or your application form is behind a puzzle or something - I 100% guarantee if you post your job broadly and interview everyone who applies you will have a very bad fizz buzz rate (and probably go insane), and I believe that if you do filter but try to keep an open mind to non-traditional backgrounds you will have a pretty significant fizz buzz fail rate. (I too oversee the screening of hundreds of candidates out of thousands of applicants.)
I've gotten enough candidates who can't FizzBuzz to say you can expect to get at least a couple in a group of 100 candidates. More or less depending on what screening you do before interviews.
There is definitely a second line above the simple FizzBuzz many more candidates would have a lot more trouble with two nested loops.
There is definitely a second line above the simple FizzBuzz many more candidates would have a lot more trouble with two nested loops.
Several years ago I asked a potential programmer candidate what their favorite operating system was and they replied "MS Office". I couldn't end the interview quickly enough.
I agree about FizzBuzz.
But how often do interviewees showing up with gross clothes, swear, or be rude to interviewer?
I'd say almost 0?
But how often do interviewees showing up with gross clothes, swear, or be rude to interviewer?
I'd say almost 0?
Funny that this was brought up. I agree fully that it's rare. But...a friend of mine was "den mother" for graduate students in a top 20 comp sci program. The students were often doctoral candidates but could also be MS students doing a thesis. A large part of her job was prepping them for interviews with companies like Google, MS, Oracle, etc. Here are a few gems she had to remind/inform them of.
"Yes, you have to shower the day of an interview."
"It's never acceptable to pull out your lunch and eat in the middle of the interview, please don't do it again."
"Yes, you have to wear something other than the shirt you slept in."
"Yes, you have to shower the day of an interview."
"It's never acceptable to pull out your lunch and eat in the middle of the interview, please don't do it again."
"Yes, you have to wear something other than the shirt you slept in."
If I was going to an interview with a company like that, I would want to know - will they reject me if I wear a suit? If so, what is safe to wear?
It depended on the company. MS interviewers came in khaki slacks and buttoned down shirts. Google came in jeans with lots of ink and piercings on display.
Part of my friend's responsibility was to give feedback to the interviewers. Her students were passing over MS to go to Google, despite MS offering significantly more for a salary. Their interviewers asked her for feedback to figure out why. She had to politely say that Google was seen as cooler. (The cooler impression wasn't just the image gained from the interviewers, it was the problems Google was trying to solve. But, the interviewers added to the company's image of "coolness".)
She held this position probably a decade ago and left after a few years. Things may be different now.
Part of my friend's responsibility was to give feedback to the interviewers. Her students were passing over MS to go to Google, despite MS offering significantly more for a salary. Their interviewers asked her for feedback to figure out why. She had to politely say that Google was seen as cooler. (The cooler impression wasn't just the image gained from the interviewers, it was the problems Google was trying to solve. But, the interviewers added to the company's image of "coolness".)
She held this position probably a decade ago and left after a few years. Things may be different now.
Will they reject you for that? Probably not. Would a lot of employees of tech companies (particularly west coast) interpret it as a lack of familiarity with the industry? Probably. Jeans and a button down or a button down and slacks seems pretty standard in my experience.
Not being rude to the interviewer is to social norms and personality as FizzBuzz is to programming skills.
It's so simple you wouldn't expect people interviewing to fail it, but it still happens.
It's so simple you wouldn't expect people interviewing to fail it, but it still happens.
"I'd say almost 0?"
It's definitely higher than that. It is a pretty easy thing to avoid, you'd think, but some people fail.
It's definitely higher than that. It is a pretty easy thing to avoid, you'd think, but some people fail.
I went to an interview in the UK (fancy add/marketing agency) and they (the interviewer) had such a dirty messed up t shirt on, that I would not wear to dig the garden.
Interviewing goes both ways. The company is interviewing the candidate, and the candidate is interviewing the company.
There is an asymmetry in the reaction though - being turned down by a company is regarded as just something that happens, turning down a company once you've had an offer seems to cause genuine shock.
Wouldn't that be more because people would expect the rejection to happen pre-offer if it's about anything other than compensation(turning down for compensation is normal, e specially with multiple offers)?
Two of those things is not like the other.
They are all in the same category when you consider basic professionalism.
Working is getting along in a social environment, not just coding.
Working is getting along in a social environment, not just coding.
I've been programming for 35 years and I can't fizzbuzz cause I don't know what it is. Yes, I've heard about it before cause it's mentioned on forums, and I even looked it up once, but I always consider such things childish. (I honestly don't remember anything about it.) Ask me about an algorithm and I'm there but don't play games with me.
EDIT: Just looked it up. Yep. A game. Now compare that to my years of accomplishments and you'll say asking me to write fizzbuzz childish, too.
EDIT: Just looked it up. Yep. A game. Now compare that to my years of accomplishments and you'll say asking me to write fizzbuzz childish, too.
Fizzbuzz isn't a trick questions that you have to have heard of. It's designed to be an EXTREMELY easy question, answerable by anyone with even a basic knowledge of programming. It's not a game. It's a way to weed out people that don't know anything.
If you have been programming for 35 years, you'll probably be appalled by how easy it is. Look it up.
If you have been programming for 35 years, you'll probably be appalled by how easy it is. Look it up.
I never said it was a trick question. Where did you and the other guy come up with that?
It may be easy but you would have to explain it to me if you were interviewing me.
After looking up what it is, as I said I did, yes, I could do it easily but don't ask me to code your game "fizzbuzz" as if I would know what it was.
It may be easy but you would have to explain it to me if you were interviewing me.
After looking up what it is, as I said I did, yes, I could do it easily but don't ask me to code your game "fizzbuzz" as if I would know what it was.
No-one remotely confident would ever fail a candidate for not knowing what "fizzbuzz" means. But any competent interviewer would fail a candidate who, having have "fizzbuzz" explained to them, could not implement it.
In internet discussions, people say "write fizzbuzz" because it's a well known trivial problem.
In an interview, they ask you to print the numbers 0..n to the screen, while replacing numbers divisible by 3 with the string literal fizz, and numbers divisible by 5 with the string literal buzz. The biggest trick or gotcha is that they will also specify that numbers divisible by 15 should be replaced with 'fizzbuzz', but they'll probably say 3 and 5 instead of 15.
If your list of accomplishments is really as impressive as you say, you can write a loop, a conditional, and use the modulus operator. And honestly if someone couldn't figure out modulus, they might still be able to pass. (But I'd be VERY curious about their background)
Fizzbuzz is not a trick question. It's not a difficult question. It's not meant to make you look stupid if you know how to program. It is only meant to check whether you understand conditional logic and looping. It's intentionally chosen to be the lowest of low bars, because there are so many people who literally can't program but apply anyway. All it's meant to do is weed out the people who have never programmed in their life.
In an interview, they ask you to print the numbers 0..n to the screen, while replacing numbers divisible by 3 with the string literal fizz, and numbers divisible by 5 with the string literal buzz. The biggest trick or gotcha is that they will also specify that numbers divisible by 15 should be replaced with 'fizzbuzz', but they'll probably say 3 and 5 instead of 15.
If your list of accomplishments is really as impressive as you say, you can write a loop, a conditional, and use the modulus operator. And honestly if someone couldn't figure out modulus, they might still be able to pass. (But I'd be VERY curious about their background)
Fizzbuzz is not a trick question. It's not a difficult question. It's not meant to make you look stupid if you know how to program. It is only meant to check whether you understand conditional logic and looping. It's intentionally chosen to be the lowest of low bars, because there are so many people who literally can't program but apply anyway. All it's meant to do is weed out the people who have never programmed in their life.
I never said fizzbuzz was a trick question.
The OP said that one should know how to write a fizzbuzz. I said I couldn't cause I don't know what it is. That doesn't mean I couldn't once it was explained to me.
The OP said that one should know how to write a fizzbuzz. I said I couldn't cause I don't know what it is. That doesn't mean I couldn't once it was explained to me.
My point is that they clearly didn't mean you should be able to write one from hearing the word fizzbuzz. It's used by name online because it's fairly widely known around these parts. In an interview question it would be given to you as a set of requirements, not just the word fizzbuzz.
You wouldn't be asked to "fizzbuzz". You would be asked to write an extremely trivial program, which would take you about 3 minutes.
Also, if you have guaranteed years of experience, fizzbuzz isn't for you. However, a suprisingly large number of applicants who can write an impressive looking CV can't write it.
Also, if you have guaranteed years of experience, fizzbuzz isn't for you. However, a suprisingly large number of applicants who can write an impressive looking CV can't write it.
I've also "heard" that the ratio of people who fail at fizzbuzz is truly disturbing even if they have impressive CV's.
It makes me wonder, though. Has anyone ever just admitted they failed at fizzbuzz here on HN?
I can imagine someone bombing it if they're nervous or if they forgot the modulo operator in their language of choice and got lost doing it an "ugly" error-prone way because they were too embarrassed to change tack once started.
If someone reasonably competent were to spend years working with some limited api's, on a codebase that has hundreds of man-years on it, could they fail at fizzbuzz when asked out of the blue? I think so.
It makes me wonder, though. Has anyone ever just admitted they failed at fizzbuzz here on HN?
I can imagine someone bombing it if they're nervous or if they forgot the modulo operator in their language of choice and got lost doing it an "ugly" error-prone way because they were too embarrassed to change tack once started.
If someone reasonably competent were to spend years working with some limited api's, on a codebase that has hundreds of man-years on it, could they fail at fizzbuzz when asked out of the blue? I think so.
I've wondered before how many of the "OMG tons of candidates can't fizzbuzz" anecdotes come down to messing up syntax or forgetting the name of something in the language they're using and mixing in something from another language, or making a plausible but incorrect guess. I could definitely see doing those things in an interview, and I've usually been considered the "smart one" or one to come to with weird/low-level/architecty problems where I've worked. Hell I know for a fact I once used the wrong friggin' method invocation syntax in an interview. That stuff barely has any place in my long-term memory, I mostly rely on context to get it right when doing real work.
I can also see a lot of folks forgetting about the modulus operation and doing something uglier and smug interviewers deciding that means they're a fraud and/or an idiot. I've only used it a handful of times in real code, in... oh man, over 15 years. If it hadn't been (for some reason) among the first things I picked up when first learning to write code it might not be as relatively-well stuck in my head as it is.
I can also see a lot of folks forgetting about the modulus operation and doing something uglier and smug interviewers deciding that means they're a fraud and/or an idiot. I've only used it a handful of times in real code, in... oh man, over 15 years. If it hadn't been (for some reason) among the first things I picked up when first learning to write code it might not be as relatively-well stuck in my head as it is.
It depends—when I was at one of the really visible companies, it wouldn’t have surprised me if as much as a third of the people I screened had lied on their resume. I’d ask folks to write functions to count the number of times the letter ‘a’ appears in a string, stuff like that. Did not need to compile or run.
I had a person break down and confess, and we spent the rest of the interview talking about how their codecademy lessons were going.
I had a person break down and confess, and we spent the rest of the interview talking about how their codecademy lessons were going.
That turned out surprisingly wholesome.
I really don't think it is very many. There are clear patterns of failure for fizzbuzz - the biggest is the "copy-paste programmer" who sees a blank canvass and just has no idea where to start. Then you have your people who can write conditionals but can't reason about them - they will very often end up with a solution that compiles, but always prints the number no matter what, or never prints FizzBuzz, or some other obvious error that should be apparent on a quick review of ones code. Most of these people also take 10-15 minutes to write it out, where competent programmers consistently bang it out in five minutes or less. (And yeah, some of them probably know it by heart by now. Oh well.)
Screening someone who just absolutely can't program at all is, IMHO, by far the worst part of technical interviewing.
Screening someone who just absolutely can't program at all is, IMHO, by far the worst part of technical interviewing.
[deleted]
> a suprisingly large number of applicants who can write an impressive looking CV can't write it
There was another HN thread recently where posters were ardently justifying lying on their resumes.
There was another HN thread recently where posters were ardently justifying lying on their resumes.
Anyone who can claim to be able to code at least a bit should be able to implement FizzBuzz. As such, it's a childish joke for most programmers.
But the alarming thing is that I've read there are people coming to programming interviews who can't fizzbuzz despite the experience listed in their CV. While rather unbelievable, if it really is true then it only makes sense to ask candidates to write FizzBuzz in the first screen before they waste any more of the teams' time.
But the alarming thing is that I've read there are people coming to programming interviews who can't fizzbuzz despite the experience listed in their CV. While rather unbelievable, if it really is true then it only makes sense to ask candidates to write FizzBuzz in the first screen before they waste any more of the teams' time.
No sane interviewer says "write Fizzbuzz" as if you should already know what the name means. They give you the specification.
That's what I'm saying.
FizzBuzz is much less of a game and much simpler of an algorithm than e.g. looking up something in a sorted binary tree. Do you have a problem with the latter as an interview question?
No I don't and that's my point.
An awful lot of programmers have very high and entirely unjustified view of their programming abilities. I'm sure they find the hiring process weeding them out to be very frustrating.
This would be more applicable if the interviewing process had any correlation with on the job expectations. Working on a job also requires:
1. Communication about expectations with team lead, PM and other stakeholders, vetting requirements, and pushing back where necessary.
2. Writing tests that cover as many edge cases as possible (This actually takes just as long as coding a feature if done right)
3. Understanding the pipeline and release cycle, and being able to build new hooks
4. Look at stack traces to debug application crashes. This usually involves debugging code that other people have written.
5. Review other engineer's merge requests, and communicate in a emotionally aware manner.
A leetcode/hackerrank type interview does not test any of these skills. If I work on improving these skills that make me an amazing engineer, it does not get me far in a typical interview, hence my frustration with their "weeding".
A leetcode/hackerrank type interview does not test any of these skills. If I work on improving these skills that make me an amazing engineer, it does not get me far in a typical interview, hence my frustration with their "weeding".
And then there are those of us who, even with an overwhelming amount of evidence to the contrary, feel incompetent.
Yes, I know about impostor syndrome. I know a few who've confessed to me they suffer from it - and I sure prefer to work with them than the delusions of grandeur types who waste my time.
I conduct the technical part of interview in my company. There are many candidates which charm our director and HR. They recite the buzzwords flawlessly and their resumes are top notch. When they come to technical part of interview, they charm us as well. Until they start coding. We ask two easy coding tasks (one programming, one data science) and so many candidates have issue with transfering algorithm they conjured on the spot into code; or are unable to solve problem on abstract level (and not hard-code the values for problem given to them). It is not uncommon that we identify sweet talkers which would have negative productivity for the company (meaning we would spend more time/money into fixing their code than they would bring value). I am firm believer that software developers must pass technical part of the interview.
Still relevant: http://www.aaronsw.com/weblog/hiring
I'm going to speak with a potential employer quite differently than I will with a friend. Trying to artificially move yourself into that category is not going to work and will just make me even less sure of the process.
At least with a standard interview format I know what the interviewer wants. If you flip that on me and put me in a position where I have no idea whats going on, it's not going to end well.
One of the biggest issues is the industry as a whole operates on a completely different hubris level. I don't think any of my professional references has ever been contacted with the purposes of gaining significant insight into my prior accomplishments or to get information about what it was like to work with me. Nope, all we need is some fancy data structure and algorithm knowledge and a white board to find that great candidate.
And those that do care about past accomplishments seem to be more interested in public Github repos.
However, it's my guess there's some sort of inflection point because I doubt Pike or van Rossum did any white board problems when they were hired at Google. My guess is their interviews were much closer to the way the rest of the world, the world outside software development, conducts interviews.
And those that do care about past accomplishments seem to be more interested in public Github repos.
However, it's my guess there's some sort of inflection point because I doubt Pike or van Rossum did any white board problems when they were hired at Google. My guess is their interviews were much closer to the way the rest of the world, the world outside software development, conducts interviews.
It's better to let good/great people slip away then to get a bad apple onto the team. Or worse, a mediocre one who never does anything wrong but also isn't contributing positively either.
If everyone only wants “great” people, where are the mediocre people supposed to work? Think like this long enough and soon the have-nots are plotting a revolution.
Companies with defined, well established revenue streams need to build mentoring programs that turn mediocre developers (solid C) into good (solid B) developers. Those employees tend to be the most loyal and are capable of a great amount of menial to boring coding tasks without complaint. Why do we devalue the grunts? They are the bedrock of every organization.
It’s not like Google’s Adwords is undergoing a complete code rewrite every quarter. Neither is Microsoft Word. Most code changes are incremental, and people need jobs, so why do we denigrate them so?
Plus A players are only usually A in their requisite subdomain. A crack coder of financial systems is going to struggle mightily when writing a morphological filter or a seam carving algorithm. There’s real value to the business when an individual acquires domain knowledge, especially when the domain is not fundamentally exciting (e.g. finance, geology).
Companies with defined, well established revenue streams need to build mentoring programs that turn mediocre developers (solid C) into good (solid B) developers. Those employees tend to be the most loyal and are capable of a great amount of menial to boring coding tasks without complaint. Why do we devalue the grunts? They are the bedrock of every organization.
It’s not like Google’s Adwords is undergoing a complete code rewrite every quarter. Neither is Microsoft Word. Most code changes are incremental, and people need jobs, so why do we denigrate them so?
Plus A players are only usually A in their requisite subdomain. A crack coder of financial systems is going to struggle mightily when writing a morphological filter or a seam carving algorithm. There’s real value to the business when an individual acquires domain knowledge, especially when the domain is not fundamentally exciting (e.g. finance, geology).
The truth is that everyone actually hires mediocre people, otherwise we wouldn't get so many comments about mentor people on teams and performance reviews would look very different.
That said, very few people think of themselves as average. Just looking at the comments here on hacker news, everyone feels they are the A players and if they aren't selected for something it's because management sucks or they aren't understood, or some other excuse.
We could all stand to be a hell of a lot more humble.
That said, very few people think of themselves as average. Just looking at the comments here on hacker news, everyone feels they are the A players and if they aren't selected for something it's because management sucks or they aren't understood, or some other excuse.
We could all stand to be a hell of a lot more humble.
>Companies with defined, well established revenue streams need to build mentoring programs that turn mediocre developers (solid C) into good (solid B) developers. Those employees tend to be the most loyal and are capable of a great amount of menial to boring coding tasks without complaint.
In general, when coding, if you're doing a menial or boring task you're doing something wrong. E.g. I've worked with a ton of mediocre developers who don't automate the menial tasks and end up doing the task manually, sloppily and slowly.
>It’s not like Google’s Adwords is undergoing a complete code rewrite every quarter. Neither is Microsoft Word. Most code changes are incremental,
Incremental changes are hard. Incremental changes to large and unwieldy systems while leaving them in a maintainable state are very hard (actually, from what I've heard, Google Adwords' code base is a mess).
>Plus A players are only usually A in their requisite subdomain. A crack coder of financial systems is going to struggle mightily when writing a morphological filter or a seam carving algorithm. There’s real value to the business when an individual acquires domain knowledge
It's vastly better to have a really good product owner/manager who knows the domain working with a really good coder than a mediocre coder with mediocre domain knowledge.
In general, when coding, if you're doing a menial or boring task you're doing something wrong. E.g. I've worked with a ton of mediocre developers who don't automate the menial tasks and end up doing the task manually, sloppily and slowly.
>It’s not like Google’s Adwords is undergoing a complete code rewrite every quarter. Neither is Microsoft Word. Most code changes are incremental,
Incremental changes are hard. Incremental changes to large and unwieldy systems while leaving them in a maintainable state are very hard (actually, from what I've heard, Google Adwords' code base is a mess).
>Plus A players are only usually A in their requisite subdomain. A crack coder of financial systems is going to struggle mightily when writing a morphological filter or a seam carving algorithm. There’s real value to the business when an individual acquires domain knowledge
It's vastly better to have a really good product owner/manager who knows the domain working with a really good coder than a mediocre coder with mediocre domain knowledge.
>In general, when coding, if you're doing a menial or boring task you're doing something wrong. E.g. I've worked with a ton of mediocre developers who don't automate the menial tasks and end up doing the task manually, sloppily and slowly.
That’s total BS. Development is full of boring mediocre tasks such as fixing spelling mistakes in UI controls, updating help messages for dialog boxes, or porting the product from one build system to another. In many tasks, there’s a huge gap (a chasm sometimes) between manual intervention and complete automation. I’ve lost count of the number of times a clever programmer has tried to automate the process and completely mucked things up, forcing me to go in and fix things manually.
>Incremental changes are hard. Incremental changes to large and unwieldy systems while leaving them in a maintainable state are very hard (actually, from what I've heard, Google Adwords' code base is a mess).
That’s exactly where a great product manager can mentor a mediocre developer in making a sensible change. It’s a great learning opportunity that we’re depriving people of because software founders want to retain all the revenue for themselves.
>It's vastly better to have a really good product owner/manager who knows the domain working with a really good coder than a mediocre coder with mediocre domain knowledge.
Of course. It’s also vastly better that to be born rich so one doesn’t have to work at all. Ideally, all developers in the market would be great developers. But they’re not. So I ask again, what are the mediocre developers supposed to do?
That’s total BS. Development is full of boring mediocre tasks such as fixing spelling mistakes in UI controls, updating help messages for dialog boxes, or porting the product from one build system to another. In many tasks, there’s a huge gap (a chasm sometimes) between manual intervention and complete automation. I’ve lost count of the number of times a clever programmer has tried to automate the process and completely mucked things up, forcing me to go in and fix things manually.
>Incremental changes are hard. Incremental changes to large and unwieldy systems while leaving them in a maintainable state are very hard (actually, from what I've heard, Google Adwords' code base is a mess).
That’s exactly where a great product manager can mentor a mediocre developer in making a sensible change. It’s a great learning opportunity that we’re depriving people of because software founders want to retain all the revenue for themselves.
>It's vastly better to have a really good product owner/manager who knows the domain working with a really good coder than a mediocre coder with mediocre domain knowledge.
Of course. It’s also vastly better that to be born rich so one doesn’t have to work at all. Ideally, all developers in the market would be great developers. But they’re not. So I ask again, what are the mediocre developers supposed to do?
>That’s total BS. Development is full of boring mediocre tasks such as fixing spelling mistakes in UI controls, updating help messages for dialog boxes
I would say this counts for much less than 1% of what I have to do. A lot of this stuff is in files which I can give product owner control over, too.
>or porting the product from one build system to another.
And this isn't boring. Build systems are tricky and filled with pitfalls. The worst thing you can say about build systems is that it's not a prestigious task.
>I’ve lost count of the number of times a clever programmer has tried to automate the process and completely mucked things up, forcing me to go in and fix things manually.
Yeah, and fixing things manually in that case is boring. As I put it above "if you're doing a menial or boring task you're doing something wrong" and you precisely described "something wrong".
>That’s exactly where a great product manager can mentor a mediocre developer in making a sensible change.
Product managers are not the right people to teach this kind of thing.
>Of course. It’s also vastly better that to be born rich so one doesn’t have to work at all.
Unlike being born rich, which is out of your control, you are able to exercise some degree of control over whom you work with.
I would say this counts for much less than 1% of what I have to do. A lot of this stuff is in files which I can give product owner control over, too.
>or porting the product from one build system to another.
And this isn't boring. Build systems are tricky and filled with pitfalls. The worst thing you can say about build systems is that it's not a prestigious task.
>I’ve lost count of the number of times a clever programmer has tried to automate the process and completely mucked things up, forcing me to go in and fix things manually.
Yeah, and fixing things manually in that case is boring. As I put it above "if you're doing a menial or boring task you're doing something wrong" and you precisely described "something wrong".
>That’s exactly where a great product manager can mentor a mediocre developer in making a sensible change.
Product managers are not the right people to teach this kind of thing.
>Of course. It’s also vastly better that to be born rich so one doesn’t have to work at all.
Unlike being born rich, which is out of your control, you are able to exercise some degree of control over whom you work with.
I always burst out laughing when I hear this. Mostly because the people saying it assume that themselves are not mediocre but good/great people.
Reminds me of the anecdote when a Google hiring committee in Kirkland was tasked to judge each other's original (anonymized) interview feedbacks and everyone failed everyone else.
Reminds me of the anecdote when a Google hiring committee in Kirkland was tasked to judge each other's original (anonymized) interview feedbacks and everyone failed everyone else.
Hyperbolic much? How can being "mediocre" be something bad? That's litterary litterary an ordinary programmer.
"Mediocre" is virtually always considered "poor" in the USA, even though the literal definition is "middling or average." Anyone would consider going to an average restaurant, but we'd avoid one someone described as mediocre.
If I want a lot of OK sushi I go to a place I trust for that. It's mediocre, but priced accordingly; and thus has good value for the money.
I think a lot of responses to this are missing something unsaid here: a single interview day for someone doesn't always give them a chance to be their best selves. That's ok but you do what you can given this fact. The whole thing is about being risk adverse with who you bring on to the team. This is the right thing to do because bad hires are exceptionally costly. It isn't a judgment on the candidate's innate value as an engineer, it's about a single sample of the "is this person a good fit for our team" function, which is different!
I just read someone talk about job post on linkedin with over a thousand applications. Are people on linked in truly mediocre that not one out of a thousand can fill the position?
Maybe hundreds could, but only one of them was having a really good day on the day of the interview. Which is why candidates have to do so many interviews and companies have to interview so many people.
I think many companies don't have exactly 1 job posting for 1 seat. For example, I've seen large tech companies have a single "Backend engineer" req that is used for every backend engineering role in the company (or org). So the pure number of applicants in a LinkedIn job post may be misleading.
Daniel Kahneman, a Nobel laureate noted for his work in judgment and decision making, stated in an interview earlier this year that interviews are terrible at choosing the best candidates. Unfortunately, he didn’t articulate alternatives.
The alternative is certainly the big problem.
The other big problem is not even giving an interview to a great candidate based on things like a resume and possible a cover letter.
The other big problem is not even giving an interview to a great candidate based on things like a resume and possible a cover letter.
I feel like this is the much more complicated and secretly much worse problem, not just for businesses, but for society as a whole.
We lean on heuristics like pedigree, both corporate, which is reflexive on having already past a hiring filter before, and academic, which is ludicrously expensive, both in time and money, is itself largely reflexive on having been born into high socioeconomic status, and seems to have dubious value outside of providing an easily digestible signal to get past these filters constructed in the labor market.
Maybe if we could design a better interview system and more accurate and precise cheap signals for who to throw into that (expensive to scale) pipeline, we could save young people from having to start their lives 4 years later and behind the starting line, reaping the productivity gains of the labor market gaining those extra 4 years and a wider pool of talent, while also creating more socioeconomic mobility spread more widely across society.
We lean on heuristics like pedigree, both corporate, which is reflexive on having already past a hiring filter before, and academic, which is ludicrously expensive, both in time and money, is itself largely reflexive on having been born into high socioeconomic status, and seems to have dubious value outside of providing an easily digestible signal to get past these filters constructed in the labor market.
Maybe if we could design a better interview system and more accurate and precise cheap signals for who to throw into that (expensive to scale) pipeline, we could save young people from having to start their lives 4 years later and behind the starting line, reaping the productivity gains of the labor market gaining those extra 4 years and a wider pool of talent, while also creating more socioeconomic mobility spread more widely across society.
Maybe making the 'extended interview' process more formal would be a good thing.
Formally have an internal 'contract' worker process where anyone they might want can be hired in to a trial pool, and projects can bring in the trial worker for small things quickly (maybe writing unit tests, or a fresh set of eyes, etc).
Every month review performance, make a decision to offer job as X, keep on for another month, or let go.
As a different part of this, alternating weekends might also be a more focused part of this, let someone that ALREADY has a job have a similar trial process on just some weekends, maybe with a more remote-work focus.
Formally have an internal 'contract' worker process where anyone they might want can be hired in to a trial pool, and projects can bring in the trial worker for small things quickly (maybe writing unit tests, or a fresh set of eyes, etc).
Every month review performance, make a decision to offer job as X, keep on for another month, or let go.
As a different part of this, alternating weekends might also be a more focused part of this, let someone that ALREADY has a job have a similar trial process on just some weekends, maybe with a more remote-work focus.
Why in the world would anyone be interested in doing this? Companies are competing for talent, not the other way around.
Because there are people out there looking for work. It's not trivial for all programmers to find a job. I am in particular really awful at the entire applying and interviewing process (except funny little algorithms problems, I can kill those). It's a stressful, amorphous blob of everything I hate.
What the parent of your comment describes sounds a lot like a specific kind of contract-to-hire, which if it's done well can be really effective. I get to show off that I can actually develop software well, a company gets to judge me on more than just an hour (or maybe a day) of questioning.
Unfortunately it can be pretty exploitative if done wrong. It's easy for it to become an unending period of low-paid work where you're just hoping that one day it'll turn into a real job.
What the parent of your comment describes sounds a lot like a specific kind of contract-to-hire, which if it's done well can be really effective. I get to show off that I can actually develop software well, a company gets to judge me on more than just an hour (or maybe a day) of questioning.
Unfortunately it can be pretty exploitative if done wrong. It's easy for it to become an unending period of low-paid work where you're just hoping that one day it'll turn into a real job.
It's more accurate to say that the current format of asking algorithm questions is not the best way to judge programmers ability. All it tests is how much has the programmer memorized for the interview and not really how he codes in the real world.
But i dont see this changing as most interviewers have been through the system and are likely average programmers themselves.
But i dont see this changing as most interviewers have been through the system and are likely average programmers themselves.
I am approaching 1.5 decades as an employed software engineer. Interviewing culture seems to change a little over the years, but usually in other wacky directions that leave me feeling entirely disengaged from the industry. I also very much love my vocation, though it alone is not enough to keep me enduring through the insanity of technical interviews , "cultural fit" assessments, and the violence of linear reductionism.
Articles and discussion threads like this are pretty much the only reason Im willing to interview at all (and thus remain in the industry). So thanks for sharing, Im glad to know other people are aware of how bonkers this is.
The long version takes years of explaining.
The short version is: I am highly allergic to cognitive dissonance.
Articles and discussion threads like this are pretty much the only reason Im willing to interview at all (and thus remain in the industry). So thanks for sharing, Im glad to know other people are aware of how bonkers this is.
The long version takes years of explaining.
The short version is: I am highly allergic to cognitive dissonance.
I'm interested in where the break-even point is. With some interview processes now stretching over 15-20 hours or even more, it seems at some point the process is not helping make a better decision and just demanding extra resources from both the hiring company and the interviewees.
This is why onsite rounds last 4-7 hours instead, while speaking to 5-10 engineers.
The underlying assumption is that Daniel would have been a great fit. Can this be assumed? Even as a good engineer, his claim to fame is founding the Prime Air team. Would there have been a "What started as an idea over coffee with Gur..." moment at Netflix? Would he have just become a random developer instead? Worth nothing that Daniel actually went from Microsoft to Amazon after not being hired at Netflix, so perhaps he would have similarly churned at Netflix.
This really isn't your typical "but whiteboard interviews suck!" situation. (not to say that they don't ....)
This really isn't your typical "but whiteboard interviews suck!" situation. (not to say that they don't ....)
[deleted]
I feel that the best we can do is "does this person look good on reference and/or paper? Then if so, in the phone screen and then interview: is there any reason to believe the stuff on paper might not be true?" (that latter happens a surprising amount).
Also: "is this person a jerk?" though you have to account for the awkward things someone might accidentally say when they feel they're in a high-pressure situation.
Also: "is this person a jerk?" though you have to account for the awkward things someone might accidentally say when they feel they're in a high-pressure situation.
It's interesting that some people find that many so-called "programmers" cannot write FizzBuzz (see links in post, apart from a fun FizzBuzz version in Python):
FizzBuzz in Python with nested conditional expressions and a generator expression:
https://jugad2.blogspot.com/2018/12/fizzbuzz-in-python-with-...
FizzBuzz in Python with nested conditional expressions and a generator expression:
https://jugad2.blogspot.com/2018/12/fizzbuzz-in-python-with-...
Sometimes I think we would be better off hiring people on the spot at random.
In France we have a legal maximal 4 months trial period for employees so... This gives enough time I think.
https://www.service-public.fr/particuliers/vosdroits/F1643
In France we have a legal maximal 4 months trial period for employees so... This gives enough time I think.
https://www.service-public.fr/particuliers/vosdroits/F1643
In the United States we basically only have trial employees. There's nothing at all like French job protections.
Really? Is that in all states?
So hiring someone should be at least as easy no?
It really depends. When you are hiring senior programmers, don’t set the bar very high, then you can filter out majority of bad applications in a 60mins interview. For both hard skills and soft skills.
Then you need to spend more time for the remaining ones to find the right people.
Then you need to spend more time for the remaining ones to find the right people.
What's interesting is that most thoughtful people in the industry agree that our conventions around interviewing make for an almost hilariously arbitrary hiring process, but very few large software orgs have actually changed the way they hire.
Portfolio, portfolio, portfolio.
I could talk to someone for hours and still misjudge whether I would enjoy coding on the same project with them.
Show me reams of code that they wrote, and I will know immediately.
It's too bad that usually isn't possible.
I could talk to someone for hours and still misjudge whether I would enjoy coding on the same project with them.
Show me reams of code that they wrote, and I will know immediately.
It's too bad that usually isn't possible.
We can’t. But we also can’t interview people for weeks. So we do one hour and we go with our gut feeling. It’s a terrible way to hire, possibly the worst, except for all the other ones.
No worries. There's always that probationary period in which either party can recognise it's not a match and either do something about it, or just give it up. How long will it take you to decide? A week? Two weeks? A month?
It's not a "no worries" situation if you just left one job for another only to find out the culture isn't a good fit.
Particularly if you relocated.
Had that happen to a co-worker once. He moved (on his own dime) from Chicago down to Dallas, then got let go just three months later. He wasn't even bad, he just wasn't performing at the level I guess they wanted him to. I never imagined back when I was in school that programming, of all professions, would be as cut-throat as it is.
That only matters if you think it's possible for the people doing the hiring to be fallible, which...is not a given in this industry.
The problem is these people will have quit their previous job and maybe moved.
For most companies it's the first 90 days.
Of course we can. Its just that we can't do it right.
You can judge programmer's ability in 60 minutes. Can someone program? 60 minutes is way more than enough. How great of a programmer are they? You're going to need more than 60 minutes, unless already had a chance to look at their prior code base.
What's difficult to judge is, are they organized? are they hard working? how do they handle stress? how's their communication and attitude? do they write great documentation? do they test their code? are they a great team player? how creative are they?
Due to time constraint of an interview, someone might be more sloppy than usual. Their might be the interview stress which is different from regular work stress, interview stress can impact their communication, etc. But if we focus plainly on technical skills, you can flush that out in 60 minutes.
I'm a hiring manager, and I have never failed in hiring someone who didn't have the required tech skills. Technical ability I can always hit spot on, the tough one is determination and soft skills. Some of the folks I took chance on, who displayed terrible soft skills during interview turned out to be champs, communicate great, work hard, etc. A few that were very eloquent during interviews were a disappointment, sloppy in development, poor communication in practice, etc.
People also grow, so someone that was a bad fit/interview for you, could in a few years grow and become great. Potential is also difficult to spot.
What's difficult to judge is, are they organized? are they hard working? how do they handle stress? how's their communication and attitude? do they write great documentation? do they test their code? are they a great team player? how creative are they?
Due to time constraint of an interview, someone might be more sloppy than usual. Their might be the interview stress which is different from regular work stress, interview stress can impact their communication, etc. But if we focus plainly on technical skills, you can flush that out in 60 minutes.
I'm a hiring manager, and I have never failed in hiring someone who didn't have the required tech skills. Technical ability I can always hit spot on, the tough one is determination and soft skills. Some of the folks I took chance on, who displayed terrible soft skills during interview turned out to be champs, communicate great, work hard, etc. A few that were very eloquent during interviews were a disappointment, sloppy in development, poor communication in practice, etc.
People also grow, so someone that was a bad fit/interview for you, could in a few years grow and become great. Potential is also difficult to spot.
> You can judge programmer's ability in 60 minutes. [...] What's difficult to judge is, are they organized? are they hard working? [...] do they write great documentation? do they test their code? [...]
You answer in the affirmative, but then go on to clarify that you're excluding 95% of the job. I would simplify this to say "no, you can't".
You answer in the affirmative, but then go on to clarify that you're excluding 95% of the job. I would simplify this to say "no, you can't".
> Can this person code at all? How well?
He's trying to draw the distinction between these two questions.
He's trying to draw the distinction between these two questions.
The distinction is meaningless. No company wants someone who can merely code (as determined by their ability to solve fizzbuzz-type stuff). They want someone who can code well.
I think you're missing the point.
The purpose is to Filter out people who can't code at all.
If you've ever hired developers you know how many people show up to interviews and genuinely cannot program to save their life.
The purpose is to Filter out people who can't code at all.
If you've ever hired developers you know how many people show up to interviews and genuinely cannot program to save their life.
>>The purpose is to Filter out people who can't code at all.
You shouldn't need a 60-minute in-person interview to figure out that they can't code.
You shouldn't need a 60-minute in-person interview to figure out that they can't code.
what about someone who can code FizzBuzz well?
Thank you.
The thing that gets me about coding challenges restricted to such a short time frame is that what might seem like a simple problem can actually be pretty nuanced. This gets even more tricky when the interviewers encourage you to be "creative", which can be interpreted as meaning that one should try to be less conventional with how they code, which may mean they address an issue in a less than pragmatic way.
Last year, I interviewed with a well-known media company, and they gave me a take-home coding challenge which was essentially about building a notes application in Rails that philosophically replicated a file system; notes could exist in any part of a hierarchy of directories, but no same file could exist in multiple directories at once.
Seems pretty simple, right? Anyone with a fair amount of experience with Rails would probably whip up some models for folders and notes, folders would has_many :folders and has_many :notes, and notes would belong_to :folder, etc. A solution along those lines would probably have sufficed for the coding challenge, as it would demonstrate knowledge of Rails.
But I couldn't just leave it there. That kind of solution would have been extremely crappy in a situation where there is a huge amount of notes in deep directories. After a few hours of careful thought, I came up with a solution similar to how Amazon S3 works, where directories are really just keys in a database and the stored files(or notes in this case) are the values of those keys.
My solution had the advantage that directories and their files could be queried through simple string matching, meaning that queries scale linearly with deep and complex directory structures rather than exponentially. The only case where things might be less optimal is during directory renames, in which case all sub-directories and files would have to be found and updated, but I considered that a compromise since renames happen less often than reads and writes.
They liked my solution enough that they flew me out for an on-site interview, and they said that nobody else came up with that solution.
Would I have come up with that solution if I was given 60 minutes and had someone looking over my shoulder? Probably not. Such limitations prevent taking time to think and letting the mind ponder, which is valuable.
If that challenge was done in 60 minutes, they would have assessed that I knew Rails but probably wouldn't know how I actually approach problems.
Last year, I interviewed with a well-known media company, and they gave me a take-home coding challenge which was essentially about building a notes application in Rails that philosophically replicated a file system; notes could exist in any part of a hierarchy of directories, but no same file could exist in multiple directories at once.
Seems pretty simple, right? Anyone with a fair amount of experience with Rails would probably whip up some models for folders and notes, folders would has_many :folders and has_many :notes, and notes would belong_to :folder, etc. A solution along those lines would probably have sufficed for the coding challenge, as it would demonstrate knowledge of Rails.
But I couldn't just leave it there. That kind of solution would have been extremely crappy in a situation where there is a huge amount of notes in deep directories. After a few hours of careful thought, I came up with a solution similar to how Amazon S3 works, where directories are really just keys in a database and the stored files(or notes in this case) are the values of those keys.
My solution had the advantage that directories and their files could be queried through simple string matching, meaning that queries scale linearly with deep and complex directory structures rather than exponentially. The only case where things might be less optimal is during directory renames, in which case all sub-directories and files would have to be found and updated, but I considered that a compromise since renames happen less often than reads and writes.
They liked my solution enough that they flew me out for an on-site interview, and they said that nobody else came up with that solution.
Would I have come up with that solution if I was given 60 minutes and had someone looking over my shoulder? Probably not. Such limitations prevent taking time to think and letting the mind ponder, which is valuable.
If that challenge was done in 60 minutes, they would have assessed that I knew Rails but probably wouldn't know how I actually approach problems.
Great example. I was doing a sudoku solver for practice recently and I spent a lot of time thinking and writing small functions, to the point where I was done but without implementing backtracking (for hard puzzles). I believe readability is a top 1-2 trait and my solver code looked fantastic. I don’t think I could do that under stress of an hour interview.
> Potential is also difficult to spot.
I think that’s true, but I also think that hiring managers rarely try to look for it.
I was on an interview, and one of the reasons I didn’t get the job was because in my current position I manage a “small team.” That team is 5 people. They had 8 people to manage. I understand that each extra person adds extra challenges, but 8 is only a little bigger than 5.
I think that’s true, but I also think that hiring managers rarely try to look for it.
I was on an interview, and one of the reasons I didn’t get the job was because in my current position I manage a “small team.” That team is 5 people. They had 8 people to manage. I understand that each extra person adds extra challenges, but 8 is only a little bigger than 5.
[deleted]
I think you can filter out people who suck in 60 minutes. I think there's little chance you can differentiate between "competent" and "good+"
What's your false negative rate?
> How great of a programmer are they? You're going to need more than 60 minutes
That's clearly what the OP was saying.
That's clearly what the OP was saying.
I once sent one of the very best programmers I know for a job interview.
I have met a small handful of outstanding programmers in my > 30 years in IT and this guy was in the top five, near the top.
I had personally worked directly with him for 5 years and he was unquestionably one of the most talented programmers there is, and a nice guy, easy to get along with and great to work with. Incredibly productive, and capable of the most incredible feats of software development.
The client interviewed him and said ....... no thanks.
There you go - I have just explained everything you need to know about technical recruiting. Give it some thought - the more you think about it, the more it reveals the deepest truth about YOU and your software hiring processes.
NO-ONE - no-one ever thinks they make the wrong call when they reject a candidate - including you.
If you want to know what happened after that - I called the CEO who I knew quite well and essentially said to him "What the fuck are you doing? I sent you one of the best programmers there is - and I know this from first hand personal experience over five years - and your interviewers rejected him?". They employed him because of that and he became their chief technical architect pretty quickly.