Interviews
Introduction
I thought I’d spice things up a little. 🌶️
One thing that I’m certain nearly every developer has read up on is the interview process. How some companies will have several stages to the entire process, from application to offer & how others will be as simple as a single interview with a panel of people.
Like most, I’ve been on both sides of that table. I’ve been in many interviews where I’m applying for a job. But I’ve also been in the situation where I’m a part of a panel, interviewing candidates. But I’d like to write a little about my thoughts when conducting the interview, giving candidates a realistic & fair chance to succeed. I have found that sometimes, there are scenarios where the panel can be geared in a way where they make success a lot harder to reach. I personally don’t think that’s necessarily fair.
My View
In my ever so humble opinion, I think that the interview process should be in three or four stages so to speak. I know that might sound a bit intense & fair enough if that’s your take, but let me explain.
I think the overall process should consist of:
- A screening process.
- A take home test.
- A paired programming test.
- A technical chit chat.
I don’t believe that you should be overly had on any one of those stages. People can perform badly due to nerves, but then again, it might be that your company deals with intense situations, thus not being able to handle nerves might compromise the business. As always, context is king, but for the most part, let’s just assume that it’s a pretty average company where the stress level is pretty standard.
Screening
I think it’s quite important to have the initial screening process just to check that the candidate is keen for the role. Just to make sure it’s a mutually beneficial relationship, it’s no good hiring someone that you underpay, they’ll build some skills & experience then ultimately leave. But it’s also no good hiring someone on a good salary with great perks, only to have them sit in the corner of the room, contributing very little.
It’s quite simple, I do believe this should be a bit of a non technical stage since it’s just so simple. I really do think this should be as simple as, this is how we work, this is a list of the tools that we’re using, etc. Are you happy? Yay or nay.
Now granted, with subjects such as the tools that are being used, yeah, the candidate could prefer x, y or z & for very good reason. But you want to make a hire where they can simply hit the ground running, they can work with what’s currently there. If there’s plan to use new or different tools in the future, that’s a completely different subject matter & it’s subjective if that’s something that you want in a candidate.
In my humble opinion, I do believe that it’s a good thing if a candidate is flexible like that. Where they can work with what’s currently there, but with developers, they should have their own opinions & views. I really don’t like a yes man, because there are so many trade offs in the world of technology, and having your own views to me indicates that you’ve had some serious hands on experience. Be that working with SQL in contrast to NoSQL or a compiled language compared to a weakly typed language, etc.
Provided the candidate can provide supporting statements behind their views, then that’s awesome. Like myself, I have a love hate relationship with LINQ, I really like the concept, but there’s a lot of things I don’t like. For example, it’s a nice API to consume, but it’s really easy for some lesser experience developers to write some horrific LINQ statements. Making it harder for developers to maintain in the long run, not to mention performance gotcha’s & so on.
Take Home Test
I think a take home test is nearly always appropriate, I don’t really agree with deadlines since they’re nearly always unrealistic. Granted, there are some real world cases where you need to get work done by a certain time, but for the most part, they’re only deadlines placed by some non technical members within the business. Again, fair enough if you have to adjust your product due to law or legislation, etc, but if you just want to rush things & get things done, I honestly believe that’s a recipe for disaster.
Now I will talk more about why rushing is such a bad thing at a later date, but give your candidates a chance. Life is messy, maybe give them 2 weeks? Like myself, when I’m working, I’m usually a busy chap, but when I finish work, I also have to be a dad, a husband, a house owner, a dog owner, etc. So all in all, there’s very little time, I have to spend time with my family, I have to do some chores around the house, I have to take the dog for a walk, etc. There really isn’t much playroom in my evenings, the exception being that I simply stay up at 3am & get things done at that time of the morning.
But ultimately, I do believe that the take home test should just be an example of the developers opinions & ideas. For example, what style of coding do they use? CQRS? Do they religiously use dependency injection? Do they use functional programming? OOP? A combination of the two? The list goes on. But it gives you that insight, it let’s you decide if those skills can compliment your team as things stand.
Paired Programming Test
I also believe that there should be a paired programming test, I do believe that for senior positions you should have a hard test. Not for the sake of it being hard, but to see the thought process. If I asked someone to quickly build up a library or API to work with the IndexedDB API, I wouldn’t expect a working example in the timeframe we have, but I would expect to see how the candidate would approach the problem. Even if they just worked with implementing interfaces in TypeScript, just so they’re showing the foundations to work on.
Those are just some of the reasons why I do believe that a paired programming test is quite important. But in addition to this, it gives you the chance to ask questions, perhaps make suggestions & see how the candidate reacts. For example, you may make a subjective suggestion, where there’s no correct or incorrect answer & you can see how they handle that. Reverting back to developers having opinions, it’s one of those areas where it’s good to have a strong opinion. But the candidate should be able to read the room, have the ability to diplomatically debate the reasoning, not to mention the candidate should be able to show some degree of humility. We’re all human, sometimes we get it wrong & myself, I’m no exception to that rule.
Technical Chit Chat
The final hurdle. I still believe that this is an important phase, because there’s a chance that you may have a specialist on your hands where they may have killed the all of the other stages so far. But you might be after a jack of all trades, for instance, if you’re interviewing a backend developer, you might need them to do some front end from time to time. It’s important that you’re able to clarify that they’re able to dabble with other technologies.
One thing that still amazes me is the number of backend developers that aren’t able to write pretty reasonable SQL statements. I don’t expect an application developer to be on par with a DBA where they might know how to increase the performance by using a having clause over a where clause or vice versa, etc. But just being able to get the basics, creating a database from scratch, nothing fancy, maybe just a SQL database to store a word document-like data structure as an example.
Or infrastructure, another area where a lot of application developers may or may not excel with. In all fairness, this subject matter in itself is pretty huge, so it’s unfair to ask some horrifically challenging questions unless you’re after that expert in this subject area. But just getting a general idea of their understanding. Myself, I’m not expert in this area, but I have a general idea & I know enough to know where to go if I need to learn more. If you talk about DevOps, let’s talk about Chef or Ansible, I know what those technologies are & what they’re used for, but I’ve never personally used them myself.
Conclusion
I don’t mean to repeat myself, but as always, context is king. For the most part, I feel that I’ve justified as to why I believe that there should be at least 4 different stages to the interview process. I totally appreciate that a lot of people might be put off by the fact that I like tests. But I like reasonable & practical tests, even if that’s just building a to-do application that has a front end, that talks to a backend which then talks to a database. This doesn’t need to be rocket science, it doesn’t need to be strictly an algorithms & data structures styled piece of homework.
And with the last 2 stages that I mentioned, I believe they’re critical as it let’s you get more of a personal feel to see how they are to work with. How they think, it gives them more of a chance to communicate their thoughts & ideas, etc. I think the process should be fair on both sides, I appreciate that the tests can require some effort & free time from the candidate. However, it’s a process that must have a mutually beneficial result for the most part.
