How many people got formal training on how to interview? In each job I've been at there's been none, save for my most recent job. For the first interviews I was let loose in I've even looked around and thought "they're letting me interview someone? Don't they know I don't know what I'm doing??".
This is a problem because without training I will use the tactics I've had used against me, and follow what colleagues do. If they didn't have training themselves then I'm doomed to repeat the failures of my peers.
We are great at problem solving, but as a community we're also extremely opinionated! Admit it, it doesn't matter how supportive you are, you must have thought your colleagues are cowboys at some point in your career! Debates like "tabs vs spaces" SHOULD NOT filter into your hiring decisions. Most often a candidate will be open to changing their behaviour on stylistic issues.
Here's my thoughts on some things we can do better...
Job Descriptions
Too many requirements: Do you really need all 15 skills you listed?? Chances are there's 3 or 4 key skills a candidate MUST have. Signpost a few required skills, and have the rest under another section "nice to have". If you have too many it'll put candidates off (especially those with impostor syndrome and under-represented groups). You'll likely not get a candidate who ticks all the boxes and are more likely to end up with a bullsh*tter.
Benefits and perks: Tell me about your benefits!! How many days annual leave? Do you offer personal development time? Do you offer personal development materials like books/pluralsight/conferences? Are you flexible? Is it a strict 9-5, or can I start earlier or later? Help candidates learn the reasons you enjoy working at the company, otherwise your job and a thousand others are indistinguishable from each other.
Don't pretend you have a work-life balance: If you state you have a great work-life balance, and your hours are 9-6pm, then you don't have a great work-life balance. There's a reason Dolly Parton stared in a film and sang a song named "9 To 5", because that is the default expectation! Also if you tell me your engineers enjoy their work so much they'll work extra hours than 9-6, or work weekends there's likely something wrong in your culture and it sounds like there's pressure to fulfil deadlines.
Skill points: remember the best performing team you worked in. Did every developer in the team have exactly the same knowledge and skills? More likely someone was knowledgeable about infrastructure, another great at CI/CD pipelines, another at security/UI/best practices/architecture/that-library-you-use/databases/performance etc etc. Essentially if everyone in the team has exactly the same skills, strengths and weaknesses, then likely the software you produce will have a major gap somewhere. Look for weaknesses in your team and add those to the job spec. Other skills you have well covered in the team? Leave them off.
Salary: tell me the salary so I know whether or not to apply!!! We could be wasting each-other's time if my expectation is massively different to yours.
Home Tech tests
Drop-off rate: if you have lots of candidates that seemed initially keen but don't submit solutions for your tech test, then perhaps you need to change something about it.
Time limit: are you google?? no? then please set a reasonable time limit. 2 hours max should be enough. If you're wondering why, then candidates will likely apply for multiple jobs. If each one requires 5 hour tech tests with no guarantee of a job at the end, then I've wasted a lot of my time, it's rude!!! Most likely I'll put my efforts in the dream job, or multiple applications where the test is shorter.
Tooling: do you work with enterprise software for development productivity? I do. As a C# developer I use a paid-for version of Visual Studio (which has more features than the free version), and resharper. Without resharper it's like coding one-handed. So if this applies to the language the tech test is to be submitted in, adjust your expectations on what a candidate can achieve in a reasonable timeframe, and forgive minor issues your tooling would have offered suggestions for.
Clarity of instructions: make sure your expectations are clearly noted. For instance if you expect someone to solve a problem AND include a UI, then state that. Don't score them lower because they didn't deliver something you didn't ask for.
Set realistic expectations: don't expect a tech test to be perfect. Remember that solving the problem itself is usually a lot quicker than delivering a high-quality solution. Naming is hard, refactoring usually takes several iterations to get something well thought-out, adding full test coverage takes time.
Avoid using generic language: I was given a tech test that had heavy usage of the words repository and object in the instructions. Nothing in the description of the challenge clarified what I was making and why, it focused on the what. Repository pattern? Git repository? C# object as in an instance of a class? A general thing? A file? A string? What am I making???
Pragmatism: if someone has got limited time to solve a complex problem, and they start in a direction that would eventually solve the problem, it shows they prioritised the right things. I've seen candidates create UIs for a moderately complex logic problem, and then they ran out of time, so now they've given me an unfinished logic problem, AND an unfinished UI. We'll have time limits for everything we do at work (whether because of a project deadline or because you can't work on one thing forever), so an important skill is knowing the important areas to focus on.
Consider providing a partial implementation: this can help you get your candidate to the jist of the problem, and enable you to ask the candidate to show multiple skills. Eg you could have a partially implemented API, with a partially implemented UI, and ask the candidate to extend or fix bugs. This means now you're not focusing on the small stuff eg "I don't like their folder structure". On the day-to-day, developers are much more likely to be refactoring and extending than creating greenfield projects. It also could make a 5 hour tech test into a 1 or 2 hour tech test.
Try to focus on what the candidate did well: look for what the candidate did really well. If they didn't solve the problem in the way you wanted, or got 90% of the way, BUT showed real skill in other ways, then you probably want to take it to the next stage. You can ask the candidates in the next stage about things they didn't finish and what they would improve. Chances are, if they did a half decent submission, they may have run out of time to fix the refactoring "issues", or that if you were pairing they would be fine doing it differently
Style: are they using well-named functions/variables/classes/filenames? Did they document their work? Following any incorrect assumptions they made, is it a sensible solution non-the-less? Are there stylistic things you perhaps don't like personally, but something that the candidate could change when being onboarded? eg "we use tabs here", "cool, no problem!".
Consistency: I realised that some reviewers in our department would fail a candidate if they didn't solve all 3 problems, but others were more pragmatic and looked more holistically at the way the problems were solved. This is not fair. If 2 people review the same tech test, you shouldn't have one person decline the candidate and another waive them through to the next round. If you're using the same tech test, you should have the same criteria.
Because we don't hire people on tech test alone, it's safe to bring candidates through to the next round and quiz them further about their solution. Remember this is just a tool to test they have a capability in the language, not that they can deliver complex problems.
Interview
Stress makes you forgetful: in stressful situations you don't necessarily remember all the stuff you normally take for granted. Try to tease out the information without writing the candidate off for minor issues. It can be good to start the interview by talking about project/skills they know well to ease the candidate in. "Tell me about a project you worked on you're really proud of". Prompt the candidate with useful hints if they're stuck, don't just let an awkward silence continue after asking them a question. Likely it could be your fault for wording the question clumsily or too broadly.
Don't be vague!!: "What tech stuff do you do at ?" Ermmmm.... I'm a developer, I do tech stuff all the time, what specifically do you want to hear about? Also you just asked my responsibilities!".
Terminology: if a candidate gives you the words describing a concept, don't discard them because they didn't use the exact word you were expecting. In previous roles we described the building blocks of an angular UI as components, and the individual "modules" that make up a page as a component too (because it literally was an angular component imported into the website). I went to another company and they used the term micro-frontends. In this company they used the term BFF (Backend For Frontend) heavily, whereas previous workplaces referred to it as a proxy/facade/backing-api etc. There's lots of jargon to explain similar concepts and tonnes of material on the internet using different terms, and so the ubiquitous language in your company is not necessarily the same as I'm familiar with and vice versa.
Design patterns: We're all solving similar problems quite often but even for the same problem we each might solve it differently. So for the same reason, don't expect developers to know the exact same design patterns you do! Even for design patterns you may think are must-have knowledge, if I didn't need to use it for the problems I was solving for the last 5 years, I might have forgotton the specifics, or I didn't think of it first for your whiteboarding exercise! Better questions may be "Tell me about design patterns you use often", or "what's your favourite design pattern?".
General
Polyglots: don't immediately dismiss someone who doesn't have x years experience in the main language you use in your team. If they have similar experience in another language then they likely might have all the other skills and experience you need: knowledge of best practices, high level concepts like caching, design patterns, problem solving, troubleshooting, communication, leadership, mentoring, championing best practices. At some point your main language is likely to become undesirable or obsolete so you'll need to get a job for a language you use less often. Does that make your other skills worthless? No it doesn't. Some languages are fairly trivial to switch between, and it doesn't actually take as long as you think to get-up-to-speed if you're using it every day. Obviously not all companies have the luxury of being able to wait for an employee to get up to speed.
In Summary
Try not to focus on your own skills and strengths, think of the skills needed for the job you're hiring for. We're in an industry where there are usually 10 ways to solve a problem, so don't loose a great candidate for reasons that don't impact their ability to do a really good job.
About me
I'm a senior developer and have been interviewed and interviewed others. I'm not an expert, and am likely not good at it, but I've seen a lot of ways we can do it badly! Most of this post is from interview processes for senior roles, but lots of it applies to most levels.
Top comments (0)