How to Hire Good Engineers
siliconvict.com
siliconvict.com
It obviously varies a lot, but having worked for two Fortune 100s and a Global Fortune 500, none of what he says aligns with what I experienced or have taken part in.
Ignoring the ridiculous idea that you would show code from your current job to an external party, there's are a number of good reason why you don't expect a candidate to have "project" code to share. First, it's rather presumptuous, the idea that the candidate is spending time outside of work doing a version of their day job for "fun". Plenty of good devs and tech workers shut it off at 5pm. You also run into socio-economic barriers - they may have significant family commitments, etc that limit their time for such activities.
The most ridiculous idea is that companies utilize hiring teams to share the blame. Pure nonsense. There's a lot of reasons you don't just leave the decision to hire up to one person, the first being biases people have, some of which the author of this piece is clearly showing. For example, this quote in regards to not having code to share:
> "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 he continues and double downs on this point:
> "But surely you will miss some really good engineers who don't have any code that they can show you over a zoom call, right?
Yep, you might. I read about this one teenage girl who fell out of an airplane at 30k feet and not only survived the fall but 10 days in the Brazilian rainforest before being rescued. Exceptions are fun."
I wouldn't want this person anywhere near the hiring process. I'm sure they're very good at hiring people like themselves.
One of the best engineers I hired was a woman that took 15yrs off to raise a family and came back into the profession. Yes she didn't have a good grasp of all the current technologies but she was a /very/ quick learner and brought a whole slew of other skills that applied to the "project management" and client relations side of things. When stuff broke, our internal customers loved going to her - she worked with them to figure out what they were doing and then what the likely issues were. Sometimes she fixed them herself, especially with code she wrote or maintained, and other times she just just provided technical info and what she thought the issues were. Most of the time she was right. Sad when I lost her due to a big reorg from a couple new VPs.
This is incredibly tone-deaf considering the current status quo is basically: want a new job? Have fun studying leetcode for the next 3-6 months so you can solve the inevitable memoization puzzle you'll be asked to whiteboard in 25 minutes.
> Companies want to standardize their hiring when really they should be looking to customize it to each candidate.
This is not the right idea. You should not be customizing your hiring process to each candidate. A standard hiring process with accountability for interviewers to follow the process is incredibly important if you want to reliably hire high quality talent as an organization grows.
"Customizing" for each candidate is a great way to give interviewers permission to make the interview simple for the people they like and brutal for the people they don't. It is also a great way to overwhelm new hiring managers who are still trying to figure out how to evaluate talent as they grow their teams.
> Lots of companies want to spread the blame of a bad hire across a committee of 4 or 5 people. That is also wrong.
This is not why multiple people are involved in a hiring process. Leaving hiring entirely in the hands of one person guarantees biases make their way into the hiring process and result in a lower quality team.
Yeah, doing a custom interview process per candidate sounds like a discrimination lawsuit waiting to happen. I don't know how you could possibly defend against the claim that the interviews are designed to help some candidates and hurt others if you're literally on the record saying you actively try not to use the same interview process for all candidates.
Personally, I would have plenty of code to share, but not code that has the cohesive story that the interviewer probably wants. Most of my personal projects are small libraries, huge projects, or tiny experiments.
I would never share code written for an employer or a client, also. That is their code, not mine, and I would hesitate to work for any company that tried to ask me to share it.
The premise of this post is indeed terrible.
However, my understanding is that it is very common for code samples from current or former employers to be shared in interviews.
There's an unsaid understanding that it is not technically allowed, but I've also yet to hear that it has interfered with a potential hire.
I don't have a lot of data points on this, so if anyone else with experience doing hiring at SV unicorns can chime in, I am curious.
Line 2 is entirely correct.
Refining the details of pet projects is not a luxury that not everyone has. If the quality of the candidate was correlated, then sure. Even still, candidates who get shit done have always been the perceived best hires.
Seriously, though, for a reasonably senior position, they'll already have been employed for long enough at a high enough salary to be afforded hobby time. And if they really enjoy coding, they'll probably code something up just to scratch some itch. Or just to play with things not work-mandated.
That's not elitist. It's selecting for successful engineers who actually enjoy coding.
If the interviewer cannot determine whether the candidate is good in less than 2 hours interview session without previously made projects, it's on the interviewer.
On the other spectrum, companies are feeling too entitled for demanding pre-established projects to showcase, take-home assignments take can take days to do, without really offering any incentive to it.
Sure, there are plenty of good engineers who won't have a nice side project to bring up. And you will be auto-passing on them.
The real question is, how many bad engineers are hacking away on a side project they can show off and speak intelligently about?
He is right that his method doesn't scale. He is intentionally picking from a rather small bucket. But that bucket should be pretty high signal-to-noise. That makes his job pretty easy.
When hiring, I often try to filter for "gets stuff done". Side projects definitely help check that box. I also filter for how deep their technical knowledge is for their experience level. I love finding people who are passionate about computers and code, as they always hit above their pay grade, but don't really try to filter for this.
Now when this technique become successful and widespreadly adapted by other companies, everyone will start making minimum personal project to show, enlarging the bucket and increasing the signal until another, more effort interview style is introduced, thus reducing the signal again and repeat.
In the end it'll only take more and more time from job seeker.
Some days I just can't, I'm fried after work, and then I just hang out with the family.
Great. Two of the most common hobbies for everyone else is excluded so you have enough time to do side projects (TV here includes streaming service shows, sport broadcasts, etc.). How is this not reinforcing the idea that this purity test excludes many engineers?
Surely the most bias free way to hire would be to say yes to the first applicant. Of course this excludes engineers who are busy and were not able to apply first... so perhaps the randomth applicant gets sent a "youre hired".
I mean. Hey maybe its a better process. We have yet to see some metrics on this.
This is where data would be helpful, and why numerous people have pointed out that bringing code you wrote, IP owned by your previous employer is a no go, and why we've goal post moved instead to bringing in your personal projects.
> If they don't have code to share for whatever reason, like it is owned by their previous employer or they are fresh out of school with no code to show, pass on them.
> You have other code to share?
Data would be helpful, but I don't even know how such data would be gathered. Is there a sure-fire method to identify a "Good Engineer" from one who is not?
I interview occasionally, been working a long time. The numbers of devs I know that have such code to share is small, and I would put them all in the work-with-again bucket. I'm not sure if I would adopt this method, but I've seen worse filters :)
Most of my side projects in the last couple of years have been things to improve the product I’m working on at work. Stuff like tickets that we can’t fit into a proper sprint, but I find really intellectually interesting, e.g. building out debug tooling.
But… as the article claims, maybe I’m just not as good as I think I am… (which I’d concede, but not due to the logic presented in the post)
It'd definitely be interesting to do a code walkthrough of that, as one would still be able to explain the code, but would need to say "back then I did it this way, but now I know better and I'd do it that way" pretty often.
The first part is pretty good, but only if the interviewer is a great engineer. If the interviewer is a good engineer, they won't ask the right questions, or will misinterpret answers, and miss details. If the interviewer is a poor engineer, they will simply look for someone just like them. If the interviewer isn't an engineer at all, anyone who can talk about code will sound good enough.
The interview panel should not be skipped. You want different people in the company to look for different things based on their own experiences. And you want enough time to ask a large enough variety of questions that little things you didn't expect will come out. Just because the first interview was great doesn't mean the second won't expose a red flag. The people asking and interpreting the questions matters as much as the questions themselves.
Don't skip people just because they don't have code to show. People who have tons of personal code might also be incredibly opinionated and insufferable and think they are expert engineers when really they are just experts at building sand castles. People with no code might not like to code for fun, or might just have a bunch of half-finished embarrassing toy projects that will make them feel bad to show you. It should be sufficient to show them code and have them tell you about it.
Yes, you do want to ask deep questions. But you should also ask easy general questions, and silly questions.
Also, if you are an engineer, you probably don't understand about 50% of what hiring a person actually entails, because you have not been tasked with dealing with all the human frailties and political and economic and social and other aspects of human beings working for companies. Do not think you are an expert on hiring just because you have been hired before or performed interviews.
This wrong self-assuredness here and in other places are a huge red flag. I'll give them the benefit of the doubt and assume they were letting off steam.
It's not really that wrong. Amazon themselves had the concept of a "two pizza team"[1]. Having large teams is stupid and unproductive for the most part.
[1] https://www.theguardian.com/technology/2018/apr/24/the-two-p...
>No one is asking to share an entire codebase, but if you feel strongly about this point, that's fine. You have other code to share?
It's actually illegal, unless the code has been open sourced or the candidate is allowed to do so which I would doubt. It would actually be a red flag for me if a candidate shares work that was done for someone else without their approval.
And it should go without saying that sharing employer code could be considered theft.
Why are you interviewing?
Folks who love coding will have code to show without question. IME folks who don’t have code to show are usually the people who build the software you hate at companies.
Hire creative engineers, who build things that people want and show a genuine interest in their craft.
I don't think that, but it's just as reasonable a position with about as much grounding in reality.
I mean you could ask them about this and get a clear understanding. I also don't see people writing code in their free time as a junior trait. Most of the very senior devs I know still do.
professional photographers have great examples of personal things that they've worked on to show off their portfolio, artists use things like behance and artstation, musicins have band camp and SoundCloud, writers have watt pad / substack, and software engineers... have github.
I mean the whole reason I got into software engineering was literally to be able to conjure up my creations out of seemingly thin air. No other branch of engineering is as frictionless towards making that a reality.
Software engineers:
- "Leetcode is unfair"
- "Whiteboarding is too stressful"
- "Personal projects are biased in favor of people with too much free time..."
Bunch of self entitled prima donnas.
Why, exactly, do we expect tech workers to have side projects?
Doctors are also a service job with references but they also have a surgical record for various surgeries and a board they answer to which can revoke their ability to practice medicine.
Many mechanical engineers will have something they can show from a previous employer because for ME the field is about improving processes/machines, not the machines that are produced. Others also have CAD that they do on their free time. With 3d printers becoming more accessible I have seen some ME students/grads do some cool stuff on the side.
Chemists, that is the only one I don't know anyone in the field and a field which is not very regulated.
So, what's the deal? Why have we ingrained serious doubts when it comes to software engineering skills? Why a 10+ year experienced SE must go through a process of "proving" the skills through 5-6 interviewing rounds while a 10+ year experienced doctor doesn't?
I don't think this correlates to job regulations as some seem to be suggesting here but I also don't have a better answer myself. It's intriguing to me overall.
Problems I personally have almost never pass the point on the cost/benefit curve for which it's worth firing up a text editor, and when they do the "solution" is usually a few lines of shell or something similarly trivial. I used to get excited about personal projects, years and years ago, but that was mostly because I didn't realize what solutions already existed so was reinventing the wheel a lot. Plus I just had a whole lot more free time.
I also don't do a lot of plumbing or wiring or wall-framing or drywalling for their own sake. Though I do find a lot more good reasons to do those things in my personal life, than I find good reasons for writing code.
It’s not usually the same people saying all those things. People have different preferences.
No matter what hiring method you use you’ll find some group of people criticizing it.
In addition to learning how the candidate creates code, an experienced technical interviewer can also ideally suggest improvements, in order to explore how the candidate works with feedback, plans new features, and ships new versions.
This isn’t an “if-you-have-time” thing. Make time for this or good people are going to pass.
So, don't ask, but tell ! Bring some mess to the developer for them to hack around until it's good.
I call this more proactive process, rather than just asking.
Ask me about something I did and all of the tradeoffs involved. Ask me to show you.
It's a bigger burden for the interviewer and it's going to be harder to "be calibrated" on this kind of interview. It also makes it harder for the interviewer to sit in smug silence while the candidate fails to find the favorite "best" answer to to some treasured pet question. It forces engagement.
Unless that code were already public of course
The author of the article mentions the company is Reforge? How well do they pay and/or how prestigious are they? Are they "elite"?
Love this style. Acts as much better persuasion tactic than simply asking them, "why do you want to work at xx?"