How to freaking hire great developers by having them read code
freakingrectangle.com
freakingrectangle.com
I so strongly disagree with this. Strong coding ability is easily the most important quality I look for in my interns. For everyone else some level of coding ability is required - there is definitely some floor below which you cannot function. But anything beyond a junior engineer what I'm looking for is understanding of how coding solves a problem. How can you map requirements to scope your solutions, how does the end application shape the architecture of what you're going to write.
I think this points at a certain problem with software hiring, where you'll put a candidate through 10 interviews all of which test the same thing and if they get lucky you hire them. if they get unlucky and miss an optimization or assumption or trick in one of the interviews, too bad. Might as well do 1 coding interview per candidate, then take the resumes of all the people who pass and throw half of them in the bin - because you don't want to hire unlucky people.
What we're really often saying is "We haven't actually figured out what makes a good engineer and how to test it so we're just going to only test coding skills repeatedly".
I laughed when I first read this, but then I read it again and can see a bunch of hiring managers actually taking it as serious and good advice due to Poe's law.
No one in their right mind would jump through all of the hoops required by the software world's completely insane attempts to filter people out of their hiring processes, all while complaining about being short handed.
The obvious takeaway is that none of these companies are qualified to be writing code at all, because they can't manage themselves. How are they going to manage a codebase if they can't manage their office head count?
Counterpoint: If the only reason you learned to code was to get hired, you'd be correct. Many learn it because they are fascinated by computing, and desirous of being able to make computers do things they previously could not.
On the other hand, totally with you on hiring dysfunction.
cant read code tho, ill show myself out.
In all seriousness, I like the idea. No one seems to know how to get interviews right. I kinda liked giving the applicant a real task but on second thought reading existing code might be the realest task on a new job.
Plenty of people do, but good interview processes are highly context-dependent and not trivially transferable.
And most companies just cargo-cult something associated with a name brand, then tweak it to something they're personally comfortable conducting.
I'll quote myself from an old comment:
> Every time one of these interviewing posts bubbles up I skim it to see if the author mentions things like: company size, team composition, the nature of the work the team is doing, the nature of the industry the company exists in, the way hiring decisions are made, the desired properties of their hiring process, their offer rate, acceptance rate, turnover rate, the amount of time positions tend to stay open for, or really just anything that would offer some context on what, specifically, their interview process is optimized for or achieving.
> Nine times out of ten that stuff is absent and the post is just a bunch of opinion and conjecture.
This post is more of the same.
I feel like it was the best of both styles of interviewing. People who hate in interviewing whiteboarding can show their skills on their own time, but if you're optimizing for packing in as many interviews in as possible you haven't written any unnecessary code.
Oooo. Sorry. Hard pass. Those symbols are redefined as something else in the context in question.
I don't give a shit if you can write in your favorite lang. I give a shit you can mentally my context and ask the right questions to get productive quickly, or build up your own from scratch while trying to mesh with something already there.
...you can mentally [model] my context...
Always hoisted on own petard.
Point still stands though.
Reading + comprehension > writing.
Because it's all theater really. I've reduced the goal of my interviews to getting an answer(any) to the question "is this person a charlatan?".
There are fewer people than open positions and there are definitely fewer competent people than open positions.
I wish HR around the world would make do with what's available, filter out those who are actively harmful and focus on training.
A junior/intern can barely understand the code, has little to no knowledge of the complexities of the code-base, and can barely produce a function that will not have an unintended side-effect elsewhere...
A mid-level developer or one with a cursory understanding of the code-base/domain will grasp the general concepts and have some idea of what to fix.
The senior level developer barely needs to read the code anymore, but they can ingest the code-base quickly and understand and explain the whole code-base to e.g. a junior/mid-level effectively. They are likely to immediately know the fix, and how it will likely effect multiple downstream projects.
OFC skill can push a developer between these categories - a low-skilled senior may be closer to an upper-range mid-level developer, and a highly skilled junior may be closer to a mid-level developer, but this is how experience seems to tend to affect a developer's efficacy in my experience.
It’s not “go to this file and do X, Y, and Z starting at line 105”, but more like “Ok so it’s likely that the source of this data is coming from a feed, track down the feed consumer by grepping for [upstreamservice] in the feeds directory, and from there we can get a look at what we’re doing with the incoming feed data”
I still find seniors are terrible in that they assume they know what code is going to do without having read it, or they refuse to learn the domain first.
Sorry but having a decent team player is generally a lot more use in my opinion. Smart devs who are divas are bad, divas who thinkk they are smarter than what they are are even worse.
The more time I spent coding the more I realize that I don’t code for myself, I code for my team and if what I’m making is not painfully obvious somebody (including future me) is very likely to break something in the future because they didn’t understand what the code I wrote was supposed to do and how it was doing so.
I'd print off a piece of legacy code that was particularly ugly and ask them to review it.
I'd tell them I wasn't looking for silly stuff like parser errors and instead was just looking for their opinion on the code. How they thought it worked and how they would improve or do it differently.
It was mostly just an interview prompt with a consistent starting point that lead to interesting insights about the interviewee but generally had repeated talking points across candidates.
Contribute to existing open source! The next PR you help with is likely in a code base very different from the previous one you saw. Plus, you'll have someone give feedback on what you write.
"Before I ask my questions to candidates, I calibrate my questions against people I work with so I have a realistic expectation for how to gauge the skill of the candidates. Calibrating the questions also helps me refine them and weed out confusing parts."
Yes! Exactly!
I was once on a hiring committee that did it right. We created an interview toolkit. We then validated, tested, practiced our interviews on each other and own our people.
I've never seen another org do recruiting, screening, interviewing, and onboarding with such intent.
Like project management, requirements, architecture, QA/test... Everyone's winging it.