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.
It is mostly the responsibility of the technical interviewers to determine if the candidate is suitable.
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 disagree. Maybe not immediately, but I’ve definitely picked the wrong candidate when I had two other better candidates in hindsight.
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 a recruiter what percentage of the time are you throwing candidates at jobs to see what sticks?
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
But i dont see this changing as most interviewers have been through the system and are likely average programmers themselves.
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.
This really isn't your typical "but whiteboard interviews suck!" situation. (not to say that they don't ....)
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.
FizzBuzz in Python with nested conditional expressions and a generator expression:
https://jugad2.blogspot.com/2018/12/fizzbuzz-in-python-with-...
In France we have a legal maximal 4 months trial period for employees so... This gives enough time I think.
Then you need to spend more time for the remaining ones to find the right people.
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.
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.
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.
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.
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).
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).
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.
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.
> 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.
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.
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.
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".
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).
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.
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.
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.
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.
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".
He's trying to draw the distinction between these two questions.
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.
That's clearly what the OP was saying.
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?
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 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.
Asking because I've seen that one play out a fair few times.
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.
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.
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.
You shouldn't need a 60-minute in-person interview to figure out that they can't code.
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.
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.
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.
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.
There is definitely a second line above the simple FizzBuzz many more candidates would have a lot more trouble with two nested loops.
But how often do interviewees showing up with gross clothes, swear, or be rude to interviewer?
I'd say almost 0?
"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."
It's so simple you wouldn't expect people interviewing to fail it, but it still happens.
It's definitely higher than that. It is a pretty easy thing to avoid, you'd think, but some people fail.
Working is getting along in a social environment, not just coding.
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.
If you have been programming for 35 years, you'll probably be appalled by how easy it is. Look it up.
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.
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.
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.
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.
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.
There was another HN thread recently where posters were ardently justifying lying on their resumes.
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.
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.
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 had a person break down and confess, and we spent the rest of the interview talking about how their codecademy lessons were going.
Screening someone who just absolutely can't program at all is, IMHO, by far the worst part of technical interviewing.