All developers aren’t the same, of course, no matter how much popular culture may define coders as a singular, generic tribe of nerd. And these differences are most pronounced in recruiting and team building in the differences between a junior, entry-level developer versus an senior, experienced developer.
It is rather uncontroversial that some interviewing methods are better suited for assessing skills for an entry-level role. For example — if you have no prior work experience, your ability to solve leetcode questions during live coding, even just fizz-buzz, can be useful to prove that despite only having worked at Staples for a summer, that you know “how to code”.
It seems logical then, that simply raising the degree of difficulty for a senior developer in the same process would prove useful. But in fact, over the incredibly valuable professional experience that a senior developer has gained over the years, practically none of it involves anything like live coding in the form it takes in a technical interview. The senior developer’s primary skill growth has been in other areas: learning their company’s culture, processes and codebase; communication, both technical and otherwise; and, sometimes most important, estimation — all of which are markedly harder to assess in an hour long meeting (never mind over a Zoom).
So what are the most common methods for assessing coding skills in the technical interviewing process?
Whiteboard, in office
Pro: Common; Better for newbies; Have to know syntax/language well (no autocomplete)
Con: Not at all representative of real work done by programmers; highly variable based on non-technical traits of candidates (i.e. anxiety);
(I’m assuming none of you animals would subject someone to a remote whiteboard interview round)
Code at Keyboard (IDE or shared coding environ), in office or remote
Pro: Eliminates irrelevant factor of handwriting/space management of whiteboard; Candidate working in environment similar to real work; “Will it run” - can test if code is feasible.
Con: Similar to whiteboard; can introduce looking up answers during interview (or is this a pro, as it’s just how every dev works?)
Take Home/Assignment
Pro: Allows the developer the comfort of working in their own environment.
Con: Not all developers can take the time to do take-home tests — can feel like a big time suck/free labor to a candidate. Even with guidelines on “how long to take” the developers who are able/willing to spend more time may produce more/better results. Typically more effort to evaluate.
Project Based/Work to Hire
Pro: In many ways this is ideal in terms of gathering candidate information, and the model for most internship programs (you get hours and hours of real world data, instead of an hour in a simulation tank).
Con: You’ve just turned a one-day interview into something much more, and more expensive. Much more complex with regard to employment law, HR, etc. Close to impossible to find senior developers willing to “try out” a new gig unless already unemployed and able to freelance. More “churn” for onboarding and offboarding and training. Potential infosec considerations.
Trying to find out what’s best for your process isn’t merely a matter of taking the junior/senior split into account, either: it’s about thinking about the variables at play in each option that would hinder any candidate from performing at their best, including factors of accessibility and diversity. While there are no cookie cutter answers nor cure-alls, the misfits are obvious.
The Bullet Points for June 15, 2021
On Interviewing
🧑🏭 Call It A Nice-To-Have: This week a few articles for developers about using side projects as a way to grow their career by exploring and showcasing interests and skills [TNW, Dice].
🍞 I would point out, on the recruiting side, the absence of side projects for a candidate should not be judged negatively, as not everyone has the time/home-life/means to be able to work on passion projects.
🐛 It used to be that standard “developer advice” would include “work on an open-source project!” as a way to burnish your credentials. A lot of research, including Nadia Eghbal’s terrific book Working In Public, has been done on the state of open source, and the stress involved in being a maintainer [“Hard work and poor pay stresses out open-source maintainers” ZDNet].
On Startups
🍾 Vancouver startup Commit has raised a $6M seed to match senior engineers to early stage startups. “Senior engineers don’t want to have to go through a bunch of technical interviews anymore that test their whiteboarding skills but say very little about their actual capabilities as an engineer” writes Frederic Lardinois, preaching to the Interviewing Is Broken choir [Techcrunch]
✔️ Eightfold.ai has raised a $220M series E to use deep learning to identify suitable candidates and filter resumes [Techcrunch].
On Devex
📖 InfoQ has a great article about, and download for, the O’Reilly book “Software Engineering at Google: Practices, Tools, Values, and Culture”.
The skills required for developing good software are not the same skills that were required (at one point) to mass produce automobiles, etc. We need engineers to respond creatively, and to continually learn, not do one thing over and over. If they don’t have creative freedom, they will not be able to evolve with the industry as it, too, rapidly changes. To foster that creativity, we have to allow people to be human, and to foster a team climate of trust, humility, and respect. Trust to do the right thing. Humility to realize you can’t do it alone and can make mistakes. — Tom Manshreck
On Hiring + HR
🎃 The “Great Resignation” — with so many open jobs, and lots of pent up YOLO, experts predict as many as 40% will seek new jobs. [Axios] In case you’re reaching for a benchmark, some data suggests IT turnover is normally around 13% [Tech Republic].
🧑🏫 In the UK, Accenture is donating £450,000 to the free bootcamp Tech Talent Accelerator to train those age 18-24 without a university degree in coding, webdev and full stack development. [Computerweekly]
😷 And while much has been made about “I’d rather quit than go back to the office” recently [Business Insider]: Why has Japan refused to work from home? Perhaps, it’s the ‘presenteeism’ that has long been the focus of grind-til-you-die Japanese workplace [Forbes].