Heck of a lot of assumptions about how large companies hire without seemingly having worked for a large company.
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.
Yep, this is a way to filter out people that aren't nearly friendless nerds with no life outside of coding. I think it's fine to have that lifestyle but it's very limiting to stick to that stereotypical lifestyle for hiring engineers.
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.
> You also run into socio-economic barriers - they may have significant family commitments, etc that limit their time for such activities.
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.
I don't mind the "show me something you've coded" as an alternative to code challenges, but the way it is presented in this article reads an awful lot like it is a way to identify who the interviewer likes nerding out with the most, not the person who is most likely to be the best fit for the organization's needs.
> 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.
> 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.
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.
I'm not sure this will help you hire people who don't do self-contained projects of a certain size (1-20k LOC) and who are scrupulous about maintaining confidentiality.
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.
I wouldn't be comfortable sharing code I wrote for a previous employer because I treat that as confidential. I'd be happy to show my personal code with the understanding that it tends to be improvisational and done a bit more casually than production code. But along the way I'm sure I'd show enthusiasm discussing the architecture of my personal projects as well as my home infrastructure: everything running on VMs, control panels, private git server, Jenkins, and everything deployed to containers.
Quite elitist requirements ya got there. Give me an engineer who understands how to transform requirements into business value over one that has a sick tmux environment.
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.
Many good engineers love to code outside work as a hobby, do not make engineers that doesn't like it as automatically bad.
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.
Yeah, that this method works and companies feeling entitled is not mutually exclusive. However it works against job seeker instead. It already taking a good chunk of productive time doing interview sessions and this can only increase it more.
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.
I'm married. I have children ages 4, 6, 7, 9, 10. I don't really have much extra time. I have many side projects. I don't watch TV. I don't play games. In my very limited spare time, if I don't have pressing household chores/repairs/bills/errands/etc then I build software projects, work on home IT stuff, and read the occasional book. If I can do it, almost anyone who really wants to can.
These things aren't mutually exclusive.
Some days I just can't, I'm fried after work, and then I just hang out with the family.
> I don't watch TV. I don't play games. In my very limited spare time, if I don't have pressing household chores I build software projects, work on home IT stuff, and read the occasional book. These things aren't mutually exclusive.
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?
At the risk of being that guy, is the _entire purpose_ of the interview process not to exclude engineers , or conduct a purity test?
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.
Of course it excludes people. Some of those excluded are good people. The claim isn't made that it's some perfect process where no stone is left unturned.
No, the claim is it's a better way to hire "Good Engineers", because what's the point of a method that isn't better than the current standard of white boarding, which we know also excludes people, but has also identified "Good Engineers".
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.
It's not a goal post move. The article is explicit about the origin being from personally owned code if necessary.
> 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 :)
I don’t buy this… unless you have a tremendous candidate pool this eliminates too many people before you’ve even talked to them.
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)
I wonder how well the interviewers would accept school projects that have been done many years ago.
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.
I can see this being used as an opportunity to ask the candidate how they'd do it differently many years later. I'm not sure if it's a useful thing to ask, but it sounds like it would spark interesting conversations.
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.
>If you need more than 3-4 engineers per team, you're doing it wrong.
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.
> This wrong self-assuredness here and in other places are a huge red flag.
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.
>It's unethical to share code from a previous employer
>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.
Careful. Excluding open source, sharing code from a former or current employer sends a signal about how you're likely to handle the prospective employer's IP.
100%, I’m sure a lot of people will hate on this but it’s absolutely correct. It’s such a better measure than Leetcode, and reflects how the world actually works.
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.
One could, with as much justification, claim that someone who spends much time writing code in their free time is likely a junior or otherwise immature developer who still likes code for code's sake and can't be trusted to make good, efficient, solution-focused decisions that senior-level and higher developers must make, since the correct call may often be "do not write new software".
I don't think that, but it's just as reasonable a position with about as much grounding in reality.
> can't be trusted to make good, efficient, solution-focused decisions that senior-level and higher developers must make
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.
Yeah it's super strange to me when devs pushback on this idea of being able to showcase their personal projects, like do you seriously not have any at all besides a bunch of worthless CRUD or tutorial projects?
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..."
Yeah, it’s very common in other fields to show off side projects. Doctors have examples of all the surgeries they did for fun. Electricians can show off the small power plants they built in their basement. Chemists can walk through the meth lab in the backyard shed. Mechanical engineers can demonstrate the load bearing weight of the bridge they built over a weekend.
Why, exactly, do we expect tech workers to have side projects?
Nice analogy and a thought that could also be extended to a hiring process look-alikes in those and similar fields. I always wondered what is it that shaped the hiring process in software engineering jobs to be that full of scrutiny. Nobody outside the field runs such heavy lifting interviews.
Electricians are a service job which usually have references and reviews and a government body which is indirectly required to monitor their performance by collecting complaints.
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.
I do not follow. None of those you mentioned are personal hobby projects, they're the same kind of references you can ask software engineer for. I'm regularly asked to provide at least 2-3 contact points from my previous jobs but that's largely insufficient to get the offer and is most usually done only at the end of the hiring process (meaning that it probably does not pose a big factor).
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.
If I were any good at spotting problems for which writing novel software is a good solution, valuable enough to be worth the time it takes, I wouldn't need an employer because I'd have (or at least be a co-founder of) one or more successful software businesses. The reason I need employment as a dev is precisely because I'm not much good at finding those kinds of problems.
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.
IMO 40 hours per week, for weeks on end with very few breaks, is already a shitload of time to spend on a single activity. It's well beyond what I'd willingly spend per week, with that kind of year-round consistency, on anything, including dumb entertainment like playing video games.
Code walkthroughs can be a great way to discuss techniques with programmers.
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 is a fine way to hire engineers. It's not the only way, and it will miss out on good candidates who don't want to show their employers' code. But this process invests literally zero time in those candidates, so it's probably quite efficient.
How to tell someone has never been in charge of a meaningful number of people. Growth and scale is hard. Multiple people interviewing is to de risk bias and have minimal critical exposure to a single person to what can cost a company a lot of money (especially for engineers). Blows my mind people nerd out on things like redundancy in spacecraft/ safety mechanism yet cannot see the corollaries to social mechanisms.
The only technical things that i often asked in my interview, is how to refactor and unit test a code mess. Ability to refactor things is the only good technical thing that i need to confirm and require from a developer.
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.
Sounds good. I've never had anyone interviewing actually ask for my code. Half the time they don't even care to see or hear about my personal projects even from a user perspective.
Interviews are like dating. The sheer amount of arrogance and prejudice you have to deal with is impossible to fix. Therefore the only solution is to go to more interviews.
Yes, this! Do not ask me for leetcode. Do not ask me ridiculous puzzle questions.
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.
Programmers who can meet your extravagant demands exist, but they also demand extravagant salaries - something, I'm sure, your company isn't ready to offer.
> "This was my reason when I first joined, but I have so many more reasons to want to work here at Reforge now. My personal goal is to turn it into a $100M company. (Now they answer)"
Love this style. Acts as much better persuasion tactic than simply asking them, "why do you want to work at xx?"
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.