An HR leader once shared with me: "Because every hire is a compromise between available candidates.. there is no perfect hire, and no two candidates are truly comparable."
It's really an eye-opening statement for tech roles, and how formally taught and self-taught/transferred folks can work side by side successfully.
The unique thing about tech skills is there's more than one valid way to solve a problem or do something "right". It's hard to measure that.
Not even two CS majors who may be equivalently capable (in different ways) on the outset will be identical, nor will be the outcome of how they grow their strengths and capabilities.
I look forward to HR continuing to evolve better to understand technical roles and contributions as being beyond a binary yes/no measurement.
Current hiring practices continue not to extend well from a bricks and mortar approach to a abstracted online/digital measurement.
In the meantime... knowing how to leverage and communicate your skillet in a transferable way is really what's important. There's no better way to do that than learning to write and communicate well, and better than others.
This is also why processes are often not transferable, because the people are different.
Better leaders are always taking stock of what they have or don't have and reorienting the process rather than trying to stuff the new team into the old process.
I don't know about in modern times but historically military leaders had a lot of interest in person agnostic processes. Caesar's book is all about what he does to avoid relying on anyone having special talents.
Startups, and riskier technology ventures generally, seem to be the opposite. There you aren't Caesar, you're the Gauls. You're hoping that your team has just what it takes to overcome the odds.
In terms of concrete specifics, I've found having interviews with at least 3 engineers on the team you will potentially be working with to be really helpful for both sides to evaluate, and more specifically when the interviews are pair programming problem solving. You get to see how the candidate works through a problem and they don't have to code for an exact solution (or I don't think that should be the requirement anyways, it should be more about approach and communication than an exactly correct implementation , especially given limited time)
It's really an eye-opening statement for tech roles, and how formally taught and self-taught/transferred folks can work side by side successfully.
The unique thing about tech skills is there's more than one valid way to solve a problem or do something "right". It's hard to measure that.
Not even two CS majors who may be equivalently capable (in different ways) on the outset will be identical, nor will be the outcome of how they grow their strengths and capabilities.
I look forward to HR continuing to evolve better to understand technical roles and contributions as being beyond a binary yes/no measurement.
Current hiring practices continue not to extend well from a bricks and mortar approach to a abstracted online/digital measurement.
In the meantime... knowing how to leverage and communicate your skillet in a transferable way is really what's important. There's no better way to do that than learning to write and communicate well, and better than others.