If you are going to interview someone for the purposes of hiring them to write code, this is for you.
If you recently got interviewed and they broke any of these rules, you can politely send them a link to this page, so they can learn and improve.
Cardinal Rule #1: Though shall not remove language features
I see interviewers sometimes giving out trivia puzzles like this:
Insert this value into the middle of this array, but don't create a new array, and don't use any Array Methods (like splice, slice, shift, unshift, findIndex, map, filter, etc.).
Always ask yourself, "Do we do this where I work?". If the answer is "No", then it shouldn't be in the interview.
The point of the interview is to see if the person can do the work you do every day, so coding tests should be representative of this. You don't arbitrarily throw out features of the language when working on production code, so why would you ask someone to do that during an interview.
- Why do people do this?
- They were tormented by bad interviews and are repeating the cycle without thought
- They stupidly think that "puzzle solving" or "inane trivia" is a valuable trait in a candidate. Every company that has tried this has found that the people that do well with these tests typically end up being their worst employees.
- They are unfamiliar with the features of the language and want to place their ignorance on the candidate as a restriction in order to follow what they are doing.
None of these are good reasons.
Cardinal Rule #2: Game dev assessments are only for game devs
I feel like this should be obvious and go without saying, but the skills used for game development are different from other types of development. I have seen WAY too many Software Developers be given tasks of creating games as an assessment in the past year (snake game, reversi, tic-tac-toe, battleship, 2d platformer, rpg, etc.). Especially ludicrous when these tasks are paired with "and use Vue/React/Etc. to do it". Tools designed for the job you'd be hired for, but specifically not for game development.
Always ask yourself, "Do we do this where I work?". If the answer is "No", then it shouldn't be in the interview.
Have you had to do any form of game dev in the last year at your job? Is the person your hiring going to be creating video games as part of their job? If the answer is "no", then this is a terrible assessment. It is no different than asking them to solve problems from other programming fields (encryption, blockchain, mechanical engineering, machine learning, data science, VR/AR/XR, etc.). OB/GYN's are not asked to give someone an eye exam before they are hired.
- Why do people do this?
- In university Computer Science classes, it is common for games to be used as a way of engaging students, and letting them work on more interesting projects that would otherwise be very dry and academic. People who come from this background and lack real-world experience from having actually built and completed many projects by hand, are the most likely to force this on others.
- Some think it "will be more fun". It isn't. It sucks. Candidates are already stressed out to prove they can do the job, and then you ask them to prove they can do a different job instead. This is no different than hiring someone to build you a car and then asking them build you an airplane first as proof of skill. Yes... there are similarities, and a really good auto engineer can probably hack something together, but they aren't going to be proud of what they made and it isn't going to be representative of their skill level in what they specialize in, the thing you are actually hiring them for.
- Some prefer to not hire people solely on their skill level of the specialized task they'd be performing at this job. They, insanely, think the person will still work there 5 years from now and may end up doing something radically different. The industry average for retaining developers is less than 2 years. Though even if your company's average retention rate is 15 years, "game dev" is not a good measurement of someone's general-programming capabilities. There are far better ways to assess this.
Cardinal Rule #3: Though shalt not whiteboard
Nothing better represents the attitude of "well I had to go through this shit, so you do to" than the persistence of whiteboarding in coding interviews. This attitude is great for giving a person in power a sense of justice for having been wronged in the past, but does nothing for anyone else. Stop repeating the cycle of abuse. Use take home assessments, and don't place a time limit on them.
A take-home assessment with no time limit offers many benefits.
- Low stress. No one is looking over their shoulder, judging their every move. There is no arbitrary time limit that is counting down making them nervous.
- Using the actual tools of the job. A marker doesn't have TAB to auto-complete syntax. A whiteboard doesn't have syntax highlighting. EVERYONE GOOGLES THINGS. Don't make people feel ashamed for doing the job the way literally everyone does the job, on a computer, with access to the internet.
- Splitting up the work as you need. Not everyone has X number of uninterrupted hours to work on an assessment. Some people have jobs, meetings, clubs, dinner to cook, kids to pick up from soccer practice and to put to bed. You know? Lives? Let them pick up and put down the assessment at their own pace. It doesn't matter if they spend that X hours in one sitting or split up over the course of a week.
- It lets people put in the work. Getting your first dev job is extremely hard, because you are an unproven entity. A high risk. You are naturally going to be slower and take longer to solve a problem, especially solving it well and cleanly. You're going to make more mistakes than someone more experienced. But I've known many juniors that just want the opportunity to prove themselves and are willing to spend the time to do a good job on an assessment, even if it took them more time than anyone else. That dedication is worth letting people highlight, a time-limit robs them of this.
The key to doing a take-home assessment well is:
- Actually assess them on related skills. Meaning the test should either focus on the tech stack and type of work you routinely do, or on the fundamentals of the field. For example, in Frontend I would give a test for reproducing a single component (NOT an entire page) with just HTML/CSS. Did they write clean, semantic, accessible, markup? What approach did they do for layout and styling? Can they handle CORS and XSS? How do they do DOM manipulation? Can they write unit tests? Ideally, you'll write challenges for them that cover multiple points of value (DOM manip AND XSS in one question), so there can be fewer questions.
- No time limit and finishing does not matter. Let them take as long as they want. But strongly emphasize that NO ONE FINISHES ALL OF IT and that IF YOU FEEL YOU'VE SPENT TOO MUCH TIME ON THIS, YOU HAVE, STOP AND TURN IN WHATEVER YOU HAVE. You want the candidate to know that this is just to get a feel for their general experience level. 100% of the assessment is optional.
- Don't pay for time. It sounds nice "hey, take this assessment, we value your time and will pay you for it". But ultimately this just incentivizes all the wrong things. When there is a dollar value associated to it, it makes you question your own worth, "IS this worth my time?". Further, pricing out how much to pay just doesn't work well. Devs are typically very highly valued. If you don't pay enough for their time, it can feel insulting. Which is very bad for the company image in your dev community as this is essentially their first impression of you. Alternatively, if you pay too much for the time of a junior dev, it can be costly. If you pay a flat fee, then someone that otherwise would have been fine spending the time to do something well may start to see that the longer they spend the less value their time is worth. The solution to this is to have a "fixed time limit and fixed pay". This also isn't great. I would 100% rather take longer to show quality work that represents what I can do than to rush to meet an arbitrary deadline and show rushed, shoddy work. That's a personal decision that you take away by setting a fixed time.
Cardinal Rule #4: Though shall not use an assessment to get free work
In the above section, we outline how to properly assess a candidate. However, some, less scrupulous folks will have a mockup for something they intend on building, and just give that to candidates to get free work out of them. When they get code they are happy with, they'll send out different "mockups" to other candidates. Giving them different challenges means you aren't comparing everyone on equal footing either. Obviously, this is morally and ethically reprehensible behavior, and may even be illegal in some countries. If you do this, devs WILL FIND OUT, and they WILL talk shit about you online and in your local tech community, to (rightfully) warn others. Every company I've ever seen do this has gone out of business within 3 years of me hearing about it.
Why do people do this?
- They're scumbags :)
Cardinal Rule #5: You get what you put in
There are a lot of websites and tools that purport to give you better candidates through their pre-made, generic, systems of assessments. These all pretty broadly range from terrible to, at best, mediocre. Most fall into one of these categories:
-
Perverse incentives - Some sites give challenges, and score solutions based on two really bad metrics:
- Time: Encouraging you to rush to get a test to pass. This "first thing I can think of that works" approach is rarely a solution you'd actually want to commit and maintain in a code base. It favors speed over quality.
- Length: Rewarding you for solving the problem in the fewest characters. This is by far the worst way to judge code, beyond esoteric, niche, gimmick competitions, this isn't something you'd ever do in a real project. We have tools that automate minifying and uglifying code. Readability is almost always the most important aspect of writing clean and maintainable code. And in the cases where it isn't the most important part of your code, it's always a close second. Code golf challenges train you to write worse code.
- Algorithms, algorithms, algorithms! - There is way too much focus on writing algorithms in interviews. In reality, developers rarely have to craft complex algorithms. In fact, most of the time there is already an open source library that solves the problem for you. And you'd be better off using an existing library that has been bug fixed, versioned, tested, and used by many other devs/projects. Developer's jobs are often to write code that brings value to the company. Rarely is that effort best spent re-inventing the wheel for something unrelated to your projects core focus. With that said, simpler functions that you could believably need to write in the code you'd be hired into working on are fine to give as part of an assessment. Especially if they have non-obvious edge cases.
- Inane trivia! What's the max number of arguments that can be passed into a function in JavaScript? Who cares! It doesn't matter, and if it does, Google it.
- Word problems: Here are several lengthy paragraphs defining a problem space that has nothing to do with the type of work you're being hired for, read all of it and write up a solution to this problem.
There's a reason you aren't buying some off the shelf software to solve a problem, and are instead having developers write custom software for you. There is value in having that custom software fit your needs exactly... and there is value in having a developer that fits your needs too. Ultimately, you are hiring a developer to create something custom. So it is worth your time to create a custom assessment for exactly what you are looking for in a developer.
Your assessment and interview process should be all about what you do there regularly, or about the basic fundamentals that are relevant to the position. Leetcode isn't going to give you that.
Why do people do this?
- Primarily it is a time constraint. It is hard to justify spending existing developer time to create an assessment, when you are understaffed. However, this process can be done once and polished/reused for future hires. So it's mostly a one-time cost with minimal maintenance if done well. The return on this investment is pretty high though. A custom assessment, made in-house, will better qualify each candidate you interview for the role you are hiring.
Pillars image by Mayer Tawfik
Top comments (0)