5 ms·

I have never understood the point of HackerRank. I even got into it with fairly high-up executives at my last job for refusing to fall in-line and use it as a t

I have never understood the point of HackerRank. I even got into it with fairly high-up executives at my last job for refusing to fall in-line and use it as a tool. As far as I'm concerned all it does is exacerbate the already terrible hiring practices and hiring biases that plague the software industry. I'm now CTO of a company operating a space that's as challenging as it is esoteric. We make hardware for adding by-wire controls to some existing cars to do autonomous vehicle test/validation. We make high-fidelity, high-bandwidth data capture software for AV sensor mules. We're working on a SDLC that enforces cryptographic chain of custody and produces safety-certification evidence as a continuous delivery artifact, and we're working on a high-assurance runtime environment for AV applications. Hiring for this diversity of internal & external products would appear to be extremely challenging, but reforming/growing the existing teams and building new teams has proven fairly easy. Insofar as quality of new hires, productivity & growth of realigned staff, etc. is concerned. The challenge was in all the preparation it took to make it easy. 1. I never hire until I am absolutely certain I can identify and articulate a very specific need that aligns with a very specific set of goals. 2. I never hire until I am absolutely certain I understand the responsibilities and level of ownership required to meet those goals. 3. I never hire until I have a meaningful frontier set of models for the personality profiles (fallabilty acknowledged) that are likely to align with both those responsibilities and of the people they'll work most closely with. 4. I have candidates pair with someone or someones they'd actually work with on an actual problem being actively worked on by the team. Why contrive a pointless artifice like programmer-trivia---to guess at what the person would be like on the team---when I can make them an honorary member of their actual future team for a couple hours on-site or over video/screenshare? 5. I don't try to get a bargain on my hires. If I've managed to do all the above, then I know what I need, I know what it's worth, and I know how I need to manage my financial constraints. This is my problem with things like HackerRank. It's just a thing that hiring managers can hide behind as a kind of faux-rigor to produce a completely meaningless "score" as though such a complex thing can be distilled down into a single number and used as some common metric for comparison. Hiring is too important to the company, the team, and ultimately the candidate---whose livelihood you now partially hold in your hand---to be so fundamentally lazy about it.

plinkplonk 9y ago
I really like your overall approach, and think other hiring managers would do well to emulate a variant, but point 3 seems to be a bit 'woo'. Could you provide some more detail (or examples) of how you build a required personality profile in advance?
- im_down_w_otp 9y ago
  I'm not sure what you mean exactly by, "woo", but I can provide a little bit of context. The most important thing to note is that this has proven only meaningful or useful to me in the context of all the other things I mentioned as well. It doesn't stand on its own, ever. Mostly it's a framework for how to think about dimensions of the problem in the abstract. It's like "team architecture" analysis. I use the OCEAN trait model. I'm aware of it's limitations (and they are numerous), as well as those of other models and methods. The reason I use it is because it's a simple enough, but still rich enough, model for me to be able to partially apply on-the-fly through casual conversation, etc. For me it breaks down roughly like: 1. I think about that job that I need done and plan traits that probably map to that job. The kind of expressed traits that surface in a fastidious-finisher are very rarely also the traits that surface in a cowboy-hacker (the coarseness of the caricatures is for illustration only).So there's a sketch that looks like: O-low, C-mid, E-NA, A-mid, N-low or something for any given need. 2. I plan out the set of traits that are mandatory to be expressed (or not expressed) strongly. Like it might be the case that I need someone to be super high on C, but if they're also super high on N, and being high on N is fairly undesirable for the current situation, then that warrants further exploration. The point of this is to try to help prioritize focus on what to assess, how to assess it, reasonable confidence in the assessment, and which dimensions are fine to be really fuzzy. 3. With model priorities in place, when speaking to people there are a lot of ways to prompt, leave empty airspace, and methods of story-telling that facilitate creating safer space for a broader spectrum of interaction than is often expected in a normal hirer-hiree dynamic. These help guide filling in that rudimentary sketch. Talking about almost anything other than the job itself helps with this because it's important to try to establish a peer-like posture. With a lot of practice one can get "okay" at doing this in such a way that it can be a meaningful, but incomplete, weight in the calculus on how to proceed with a candidate as well as the team the candidate would be joining. 4. Lastly, the most important thing to do here from my experience is to bias myself toward constantly trying to rapidly invalidate my model sketch at every possible stage of interaction from the first email exchange all the way up to issuing an offer. This does a few things. It forces me to have constant and active intention in every single step of the process and every single interaction with a person. It keeps me from religiously believing in the modelling itself because it's constantly clear that it's incomplete and fallible. Perhaps most important is that it puts the adversarial focus on myself and my assessment process rather than laying that adversarial relationship on the candidate. I have to read as much or more about psychology and neuroscience as I do about byzantine fault-detection or applications of formal methods. Hiring can't be an afterthought that we as hiring-managers take lightly or try to relegate to passive tools or industry norms that seem patently ridiculous on their face. Every "bad hire", every misaligned/unsatisfied employee, and every termination is ultimately the fault of management.

plinkplonk 9y ago

I really like your overall approach, and think other hiring managers would do well to emulate a variant, but point 3 seems to be a bit 'woo'. Could you provide some more detail (or examples) of how you build a required personality profile in advance?

im_down_w_otp 9y ago
I'm not sure what you mean exactly by, "woo", but I can provide a little bit of context. The most important thing to note is that this has proven only meaningful or useful to me in the context of all the other things I mentioned as well. It doesn't stand on its own, ever. Mostly it's a framework for how to think about dimensions of the problem in the abstract. It's like "team architecture" analysis. I use the OCEAN trait model. I'm aware of it's limitations (and they are numerous), as well as those of other models and methods. The reason I use it is because it's a simple enough, but still rich enough, model for me to be able to partially apply on-the-fly through casual conversation, etc. For me it breaks down roughly like: 1. I think about that job that I need done and plan traits that probably map to that job. The kind of expressed traits that surface in a fastidious-finisher are very rarely also the traits that surface in a cowboy-hacker (the coarseness of the caricatures is for illustration only).So there's a sketch that looks like: O-low, C-mid, E-NA, A-mid, N-low or something for any given need. 2. I plan out the set of traits that are mandatory to be expressed (or not expressed) strongly. Like it might be the case that I need someone to be super high on C, but if they're also super high on N, and being high on N is fairly undesirable for the current situation, then that warrants further exploration. The point of this is to try to help prioritize focus on what to assess, how to assess it, reasonable confidence in the assessment, and which dimensions are fine to be really fuzzy. 3. With model priorities in place, when speaking to people there are a lot of ways to prompt, leave empty airspace, and methods of story-telling that facilitate creating safer space for a broader spectrum of interaction than is often expected in a normal hirer-hiree dynamic. These help guide filling in that rudimentary sketch. Talking about almost anything other than the job itself helps with this because it's important to try to establish a peer-like posture. With a lot of practice one can get "okay" at doing this in such a way that it can be a meaningful, but incomplete, weight in the calculus on how to proceed with a candidate as well as the team the candidate would be joining. 4. Lastly, the most important thing to do here from my experience is to bias myself toward constantly trying to rapidly invalidate my model sketch at every possible stage of interaction from the first email exchange all the way up to issuing an offer. This does a few things. It forces me to have constant and active intention in every single step of the process and every single interaction with a person. It keeps me from religiously believing in the modelling itself because it's constantly clear that it's incomplete and fallible. Perhaps most important is that it puts the adversarial focus on myself and my assessment process rather than laying that adversarial relationship on the candidate. I have to read as much or more about psychology and neuroscience as I do about byzantine fault-detection or applications of formal methods. Hiring can't be an afterthought that we as hiring-managers take lightly or try to relegate to passive tools or industry norms that seem patently ridiculous on their face. Every "bad hire", every misaligned/unsatisfied employee, and every termination is ultimately the fault of management.