Apparently there have been a couple of people asking about how we go about hiring programmers for BlockTrades work and I was asked to write a short post to describe the process.
Perhaps the first thing to say, and possibly the most surprising, is that we don’t generally hire programmers with previous blockchain experience. Why? There’s several practical reasons: 1) there’s a relatively short supply of such programmers and 2) they are usually ideologically-driven and have their own plans for what kind of code they want to write. Therefore, our hiring process focuses on finding highly skilled and motivated programmers who are capable of learning “on-the-job”.
When we’re hiring an entry-level programmer (i.e. a recent graduate) we don’t really require any particular programming language background, but when we’re hiring senior programmers we often look for a background in languages and programming frameworks that match up with projects we’re currently working on. Currently, this means we’re typically looking for programmers with experience in languages and frameworks such as C++, Python, SQL, and Javascript/React-js.
When it comes to programming, I think it’s important to have programmers that are only working on code, not juggling many other tasks. When you’re coding, you have to keep track of many pieces of information, and if you’re distracted by other things, its easy to forget something of importance. It’s also difficult to resume a complex programming task after being interrupted for a week or so, because you have to relearn things that have been forgotten in the meantime.
For these reasons, we almost never hire part-time contract programmers, unless it is for relatively simple tasks. Occasionally we contract out with a part-time programmer with specialized experience for a particular task, but even this is relatively rare, unless it seems likely that the code in question won’t have further maintenance needs in the future.
This final requirement is the one that places the most limitations on who we hire as programmers. Generally speaking, we only hire programmers who can work at or near one of our offices (our offices are located in Virginia/USA and Poland). This is because I favor a team approach to most software development projects, and remote work tends to result in less communication between team members.
However, after someone has worked for a year or so in one of our offices, they’ve usually absorbed enough of our programming practices that it’s not really difficult for them to work remotely and still be productive team members. So this is mainly a requirement when someone first starts to work with us and we do have many programmers who work at least somewhat remotely now (especially with Covid-19, this became a necessity, of course).
For the interview process itself, I’m usually looking for several things: 1) strong programming ability, 2) a positive attitude towards working, and 3) ability to work well with others. Perhaps not surprisingly, the most difficult hurdle in the interview is usually programming ability (and creating a properly calibrated programming test isn’t easy for the interviewer, either). When hiring recent college graduates, I find I usually need to interview 10 or more computer science candidates in order to hire one that met our needs.
I’ve found that it’s also easy to let a bias towards pleasant personalities affect one’s recollection of an interview process, so the technical portion of a programmer interview is done on paper or in front of a computer, so there’s a record of the work that was done by the interviewee that I can review later when I’m interviewing many people at once and have to make decisions about which ones to hire.
When hiring new programmers, I’ve observed that companies often don’t do a good job with the “post-hire” process. When you’re adding a new programmer to your team, it’s very important to properly introduce them to the project. This includes training on expectations about how they should be contributing to the project and assignment of suitable tasks to let them “get their feet wet” without “throwing them in the deep end”.
In large companies, the tendency is to leave new hires languishing without any real project to work on (this especially goes for the interns they hire). Or on the other extreme, it’s not uncommon for small companies to throw some overly difficult task at a new programmer, because the manager making the assignment didn’t properly gauge the difficulty of the task for someone who hasn’t previously worked on the project.
So I think it’s very important to make sure someone is monitoring the work of a new hire, to be sure they have something challenging but not overwhelming to work on, and that can make adjustments to the task assignment and provide assistance when necessary.
There’s a lot that goes into hiring a programmer and integrating them into an existing team. A good hiring process is one of the keys to success for a software development company and this post really only scratches the surface of the challenges involved. Nonetheless, I hope it will be of some use to others looking to build a software team.
