Surely this will filter out ~50% of people who are good but don’t have any public code?
I have a family and as such no free time for coding so I haven’t written any code I can legally show anyone else in more than a decade. But everyone who has employed me is more than happy with my work. Not to mention code is only half of why you would want to employ any developer.
I agree. I would be happy to provide references of the developers and engineers in my ex-teams, whether collaborators or mentees, who would give me glowing references.
Instead, I'm asked for senior-managers/directors as references... who were the reason why I left in the first place. I guess HR just wants to know I was actually employed there (tick box)
> Surely this will filter out ~50% of people who are good but don’t have any public code?
Not OP, but I follow a similar process when I have to do coding interviews. I work around the "no public code" problem easily: "great, then pick an open source library you use regularly and let's go through and look at some of the things you do with it, what you like about the API design, and some things you stumble over or wish were better".
I've had candidates go through everything from jQuery to D3 to Spring to just parts of the Java SDK.
Also, in my experience, the percentage of people who have _zero_ public code is small. Maybe 10%. Certainly not half.
> pick an open source library you use regularly and let's go through and look at some of the things you do with it, what you like about the API design ...
People who have plenty of time to prepare, eg carefully study and think about that API before the interview, will tend to do better in the interviews.
Although they aren't necessarily better at coding.
Meaning, you're slightly favoring people with lots of spare time. Not saying that's a good or bad thing, just maybe something to be aware about.
Also, what open source project they happen to choose, will matter I would think. That's a bit like tossing a coin as part of the process
>Surely this will filter out ~50% of people who are good but don’t have any public code?
It then becomes a take home assignment where you get to pick the topic.
Surely you wanted to protoype some tech but didn't have the opportunity at dayjob - so make that prototype and bring it to review.
Much higher interview value than take home assignment IMO, but you need to be competent as an interviewer to enter into a discussion on something you might not understand yourself.
And it's also higher value to the person applying because they get to protoype stuff they find interesting.
I don't see myself reviewing your 2 months of work at an interview. Showing me a prototype of something you thought was interesting and walking me through, pitching the tech and debating pros and cons would be enough for me to estimate what it would be like to work with you and my estimate of your experience level.
Yeah, but at this point you're not left with many other options other than sticking your finger in the air and hoping you can detect if they know how to write code.
Only if you are limiting yourself by the options mentioned by the top comment author :) I was interviewed many times without showing any of my code. The most effective way I saw: the interviewer gives you some code and asks you how you could refactor it, what parts you would implement differently.
I can't see how your approach can scale to hire tens or maybe hundreds of engineers.
Sounds like something that may somewhat work for you when you're the only one doing the hiring for your small team of buddies at a startup somewhere.
You're not even trying to tackle things like hiring for multiple roles, interview fairness, subconscious bias, technical diversity, feedback, or making the interview process accessible to a larger group of people that don't fit your cookie-cutter from the get go.
On a different note - I really hate the tone of your post. You come off as an arrogant person who's full of it and "has it all figured out". I'd easily pass on you just by reading these posts.
There's a difference between hiring your 2-3 buddies that'll work with you on your toy startup (many of which ended up shutting down fairly quickly, reading OP's blog) - and actually staffing a diverse team that works on a complex product that's used by many clients and is held up to a high standard.
Mature products require competence in areas such as security, architecture, compliance, devops, research and much more. Hiring has to reflect that and account for it.
It's silly and immature to suggest a 90-minute chat about some crap your candidate will bring with them is somehow the answer here (and claiming that if they don't have anything to bring with them, then chances are that they're worthless anyways and you shouldn't waste your time on them). Especially without backing this up with any meaningful data (ie. attrition, number of people hired, actual impact on business, feedback received, etc).
> Sorry to be blunt, but chances are they aren't very good, and they are definitely not as good as they think they are.
I don’t know what to tell you.
It’s just so wrong it’s kinda wild how sure you are about this. At least half of the excellent colleagues I worked with in the past 10 years don’t fit your criteria. You’d be lucky to hire any of them.
At the same time, it might sort of work, just that since they a bit randomly discard a fraction of the job applicants, the company will end up paying more, for those it hires (supply and demand). But maybe the company doesn't notice (and in the end what does it matter anyway)
Entire post can be summed up as "this is my answer, here is me rationalizing correlation=causation without any empirical evidence".
We could dissect the entire thing but really, if that is how it works for you, fine. Just don't push it onto others as the absolute truth. If this stuff was really so great, empirical research would've hammered it home decades ago. But it doesn't, and continues to struggle finding any meaningful correlations between these "whacky fun strategies" and actual job performance.
This isn't used widely because it is hard. But it's not but novel.
1. Companies want to standardize their hiring when really they should be looking to customize it to each candidate.
2. Lots of companies want to spread the blame of a bad hire across a committee of 4 or 5 people, but I think if you looked you'll find many startups doing it this way. They stop when they grow to a large size. They do it because frankly hiring good engineers is no longer the top priority (it's typically quotas AKA butts in seats).
> "My evidence isn't that great I admit. I've only helped build 3 unicorns (helped found one of them) and started 3 $1M+ companies as a solo founder."
Again with the awkward appeal to authority.
Cut straight to it. Your post's title is "how to hire actually good engineers". So how many of those have you actually hired? How many of them stayed there 2 years into their roles? How do you know you've actually hired "good" engineers, and not just people you yourself thought were good enough at the time you interviewed and hired them? Have you actually followed up on your hires 3/6/12 months into their roles, to check that they're still as good as you thought they were?
By the way - "$1M+" sounds like a particularly low budget for "actually good engineers", ironically enough.
> Sorry to be blunt, but chances are they aren't very good, and they are definitely not as good as they think they are.
and there it is, one of the other subthreads is making fun of this kind of employer that swear by showing code
this is a false attribution bias where you decided not to notice that every evaluation technique the entire industry figured out will mostly by filled with people that cant code
Hmm, and evaluation technique cannot be filled by something
One cannot fill an abstract concept like a technique with things
Maybe you mean that every evaluation technique will detect that most of the job applicants aren't good at coding? And therefore, all evaluation techniques seem to work? (Although some techniques are a lot better than others)
I have a family and as such no free time for coding so I haven’t written any code I can legally show anyone else in more than a decade. But everyone who has employed me is more than happy with my work. Not to mention code is only half of why you would want to employ any developer.