Developer Skills Report

Go on a random terminal and fire up emacs. It isn't there. Also, your favorite editor isn't there. That's why. The practical choice is Vim vs. Nano or Joe or Ed or whatever.

I can think of a dozen reasons for that, but here are a few of the most salient ones;

1. Reading and evaluating code in an unfamiliar context is really £@#&ing hard, especially on a complex project. Understanding someone's commits requires knowledge of the project as a whole, the problem space, the environment, etc. That's not possible to do for a large number of candidates. It might not give you a very good insight in to an applicant.

2. Most people's public code is of roughly equal quality (eg 'not great'). You can't really differentiate between people well based on it. What people do in their spare time for fun is rarely commented/tested/documented/etc, so it's a bad way to evaluate their skill level. If you find someone with good public code that's a great sign, but a hiring manager who's looked at 100 Github profiles and found zero good ones might reasonably have given up looking.

Also it could be seen as a discriminatory factor; if you think public code is important you're going to overlook people with little time to write any, eg those with families, care responsibilities, interests outside of coding. Building a great team is about hiring great people more that just great developers.

3. It's hard to trust someone's public code. It's trivial to clone a few open projects and take credit for the work, and a hiring manager doesn't have the time to dig in to everyone's projects to see if they've ripped the work off from somewhere.

Also, you may have dealt with 50 hiring managers who have never looked at your public code in your career so far. That isn't very many really.

I certainly wish there was a better way to evaluate developers skill, and as someone who has plenty of public work on Github I think it'd be great if that was a good starting point, but I don't think it's quite good enough yet. I can certainly see why hiring managers don't look there.

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.

Not everyone wants an IDE, though. Unix is my IDE, and Vim is just my text editor. I learned emacs first and left it for Vim.

I have never used vim/emacs before. While sshing I end up using nano. Does the job. What advantage does vim have over nano? Honestly curious.