Comment by dkarl
1 day ago
Add me to the list of people who acknowledge the problem but haven't heard any alternative. Every job opening, you encounter people who can talk and act like software engineers, but can't write code. I've been in the business for about a quarter century now, and looking back at times that teams decided to overlook someone's failure to demonstrate coding skills in interviews, sometimes it has turned out they can write code, but often not.
Younger engineers trying to find jobs in the industry should consider how much the other parts of the hiring process privilege older engineers regardless of ability. I'm sure many of the people I worked with who lacked basic coding competence twenty years ago still lack competence and are employed right now in jobs that require it, jobs that could go to younger, more capable people except that their resume, their experience, and their ability to say the right-sounding thing don't match up.
Hiring someone to write code without ever seeing them do it is like hiring a guitar player for a band by verifying their MFA in music theory, talking to them about music for an hour, and checking their references. All that is fine, but can they play the guitar? You can acquire everything else, the lingo, the knowledge of music theory, the pros and cons of competing techniques, the familiarity with current and past great performers and performances, without ever putting your hands on the instrument. And some people are built like that. Some people are guitar connoisseurs: they gave up their hopes of playing the instrument long ago, but they're huge fans and nerd out over the art and science of it. If those folks needed to be in a band to have health insurance, and they didn't have to audition, you can bet some of them could talk their way into it.
Finally, when a team interviews someone for a position that requires writing code, they are inevitably making a judgment about whether they think they can do it. If you ask someone to guess without any direct evidence, you're inviting them, almost forcing them, to fill the gap with bias. Do they collect subtle little hints and make fragile deductions like they're Sherlock Holmes? Do they trust their instincts about whether the person in front of them looks and acts like the kind of person who could code? Either one is guaranteed to be rife with bias and problematic preconceptions.
>Add me to the list of people who acknowledge the problem but haven't heard any alternative.
Credentials like doctors and lawyers. You don't ask your surgeon for a demo before going in do you? Stakes are way higher and there are obviously bad doctors too.
Bad managers do way more damage than bad developers, and I don't think I've heard of managers having to mock manage a team for an hour, and I'm sure it's just as vulnerable to bullshitting.
What it really seems like is the lower end positions get the hoops to jump through while the upper level positions (manager and staff+ ICs) have it easy despite having way more impact and being paid more.
Lawyers go through standardized postgraduate training and bar examination. Doctors go through standardized postgraduate training and examination, following by years of residency where they practice under the supervision of fully qualified doctors.
There's no standardized postgraduate training for developers. Many CS grads are about as well prepared to work in industry as a new grad with a bachelor's in biology is prepared to practice medicine. That's something that should be corrected, but nobody agrees on whose job it is to correct it, and AFAIK there are no changes on the horizon that will.
> I don't think I've heard of managers having to mock manage a team for an hour
Companies do suck at hiring managers externally, but on the other hand, I've seen bad managers get hired and fired/"resigned" in less than six months. The pay and position does seem to come with a higher degree of accountability, even if I don't always agree with how a company enforces it.
Edited to add: Licensing is an imperfect and onerous system, and we resort to it in the case of doctors and lawyers because they often work unsupervised providing high-stakes services to members of the public who aren't qualified to judge their competence or the quality of the service they provide. Hiring a developer into a software development team is as close to the opposite situation as you can get.
[dead]
+1
For me, it goes even deeper than this. I prefer the person to write pseudo code on a whiteboard. It removes the stress of syntax, speeds things up, and shows if the person can think in computer logic.
The other advantage, for me as an interviewer, is this is how I like to work with others - whiteboard sessions to discuss and exchange ideas.
I think it’s important to acknowledge that peoples’ brains function differently. Only because whiteboard sessions are best for one person to exchange ideas, there may be other ways to do so that work out just equally well. E.g., someone else may rather be confused to deal with made-up pseudo code syntax in an unfamiliar environment, and for them it may work better to explore and discuss ideas while sitting in front of a real IDE.
To me, the crucial question is whether the interview style is subconsciously biased (because the interviewer themselves fails to imagine that there are other ways to produce equivalent results, or is unable to adopt to different approaches), or whether it’s designed deliberately (because the interviewer explicitly wants to optimise and select for a homogenous collaboration style within the designated team).