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.
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).
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.
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".
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.
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.
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.
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.
