Many companies are trying to use coding tests to save time for themselves and filter out candidates for interviews. Conducting such tests in the first few rounds of the interview is not a good idea if it is done without a proper purpose.
Please show this article to employers who conduct coding tests early-on. If their response is “sorry we can’t change the process”, it’s a potential red flag. You can have an impressive GitHub portfolio, research papers, patents, and many years of coding experience. Yet these companies want you to do a coding test. Does that say something about their decision making?
A lot of candidates lose time doing these tests, and the coding exercises often do not reflect a real day at programming (don’t gaslight yourself into believing it does). Besides, passing the test is not a guarantee that you are getting a good programmer. You may also lose good candidates who don’t want to lose time doing the test (even if it’s Google’s time-wasting foobar challenge). The same applies for reasoning tests and other pointless tests. Here’s why:
Even if one spends many hours solving these problems, there’s no guarantee of getting interviewed, or of getting the job. Think of how much time is lost in doing coding challenges of multiple companies.
Understand talent
An old management book I once read, had a page where the experienced author noted that even a mediocre but well-coordinated team can beat a highly skilled team. This is something that many companies need to understand. There are plenty of intelligent people out there who have varied skillsets which may not be math-specific. They may take time to understand concepts. They may not be able to memorize a lot of information. But when they are given the necessary time, support, trust, respect and encouragement, they can use their creativity, cooperation and skills to deliver better results than anyone else.
It’s not just interviewing techniques that need improvement. Try these:
- Candidate strengths: Re-design the hiring process to understand what people’s interests and strengths are. Understand how individuals function and in what kind of environments they thrive.
- Submission simplicity: Re-design the application submission process to be simpler. Don’t make candidates fill in long forms, where they type out the same things mentioned in their CV. Give a short, clear job description and make use of the single-click “Easy Apply” options on job sites. Some recruiters have sent me boilerplate emails, asking for a list of information which was already present in my CV. Many other companies expect candidates to spend extra time creating an account on their website or on inefficient sites like WorkDay to apply for jobs. It helps to search for more efficient, automated recruitment tools and getting your boss to sign off on it, saving time and money for the company and the candidate.
- Time gap is not an issue: I’ve been asked questions about programming languages that I used many years ago, and failed interviews because of that. The recruiters didn’t understand that candidates like me, work with multiple programming languages, and refer the manuals to learn languages on-the-fly to accomplish tasks. I’ve similarly been baffled by recruiters who say I’m not eligible because I have 1 year experience in a language, and they need someone with a minimum of 2 years experience. That’s not how “software experience” works. There was a time when with one month of ActionScript experience, I built something (in 3 hours) that a consultant with 7 years experience in it, claimed was impossible.
- Check for software design maturity: Don’t conduct coding tests in the first few rounds. Doing it in the later rounds is ok, but still, making experienced candidates do coding tests similar to Google Code Jam, is silly. Some interviewers even ask some pointlessly obscure technical questions to either stomp down on the candidate’s confidence and pitch a lower salary, or simply because they saw somebody else do it and couldn’t think of better questions. Here are some things to evaluate for experienced candidates:
‣ Evaluate candidates on their ability to design de-coupled software components.
‣ Evaluate them on how well they create maintainable software.
‣ Evaluate them on how they design usable software.
‣ Check how they refer various sources or reach out for help when stuck with problems.
‣ See how they write test cases.
‣ See if they design their software to allow for dependency injection (which makes it easier to create test cases).
‣ Look at their past work for sparks of creativity and innovation.
‣ See if they take initiative to suggest better alternatives to anything you’ve suggested.
‣ Do they use loggers?
‣ Do they know how and why to use design patterns? Have they used it before?
‣ Do they know anything about internationalization, penetration testing and designing software to be disabled-friendly?
More importantly, do you and your team have the necessary software maturity?
Coding challenge winners may not necessarily be 10X-speed programmers
I’ve heard of company managements speaking of how top companies have programmers who can get work done ten times faster than others. It’s true that there are programmers who can churn out code faster than others. It’s true that such programmers may even think of all possible boundary conditions when writing code (that’s what it takes to pass the coding challenges). However, these are not the only skills a programmer needs, to be 10X. The 10X should be measured over a long duration based on:
- Whether project requirements have been understood, documented and verified with the customer.
- Whether the software architecture and design patterns have been subject to peer-review from experienced people and is as future-proof as possible.
- Whether the software language and tools have been chosen based on careful evaluation, as per the requirements and anticipated changes.
- Whether version control, test-cases, bug-trackers, continuous integration is implemented, and quality checks are performed.
- Whether the programmer and the team share a good chemistry and fit well into the company’s culture.
It only makes sense to measure the 10X over a span of many years (and you can see that it’s a team effort), so of course this can’t be evaluated objectively in an interview, but you can ask about their past experience. A programmer who delivers poorly planned code quickly may seem like a hero initially, but if they get hit by a bus, or when more members are added to a team, or when the client requests changes and the software suddenly requires a complete overhaul, that’s when you realize that the initial 10X advantage you thought you got (even in a startup), is actually a lot more costly than if you had invested time in ensuring the bulleted points mentioned above were fulfilled. I’ve seen programmers get stuck with trying to deliver quickly and then ending up losing more than triple that time, making up for errors and unaccounted factors. Moreover, working overtime frequently can also cause health complications like these.
Interviews as a service
Then there are employers who outsource interviews. A certain interview-as-a-service company designed a one hour interview, where they’d ask a simple programming question, and 45 minutes would be given to the candidate to solve it. The interviewer would just perform a robotic function of being prompted by the system to switch to various stages of the interview. So even before a candidate can fully answer a question, the interviewer switches to some other topic. This ends up creating nervousness and annoyance. An experienced, knowledgeable candidate I know, went through this interview and got rejected. On reviewing what happened, I realized that he wasn’t given time to plan the code before writing it (this is a fundamental for programming). He was a backend developer, and the interviewer was a frontend developer. So the interviewer didn’t understand much of what the candidate said. The interviewer was not even given a copy of the candidate’s resume (big red-flag). The company that outsourced their interviews, lost an excellent candidate, because this interview-as-a-service company believed in looking for hiring signals within those 60 minutes, instead of designing an interview that actually understood the candidate’s strengths and experience.
Side note: If you are a freelancer conducting interviews for these interview-as-a-service companies, be aware that many of them are charging clients a certain amount (for example, $25) and giving you only around 40% of the money (less than $9). In such freelancing gigs, they should actually be paying you 75% to 90% of the money. They try low-balling you with lousy excuses that you don’t have enough experience etc. Lack of transparency in how much they charge clients, is a massive red-flag.
Think different
I know it’s hard to design interviews to select candidates efficiently. But the time invested in improving the hiring process is well worth the investment. Instead of Googling for “how to conduct an interview”, try thinking out of the box and designing interviews based on the actual job that the candidate will be performing, and based on what the candidate is good at doing. Try designing the recruitment funnel to be efficient for you and the candidate. If you really want candidates to spend time doing your take-home coding exercises or if you want them spending an enormous amount of time going through various rounds of interviews at your company, have the courtesy to pay for their time, food, stay and/or transport (some companies do actually pay for the hotel-stay and transport. I was offered a taxi to and fro, for a FAANG company interview. They even booked two-way flight tickets for some interviewees).
I have even heard of companies that direct their HR team to invite a lot of candidates for interviews just for the sake of showing that they’ve conducted interviews (it’s called padding/pipelining). Don’t waste candidate’s time like this. Some even bluff about the job description and pay-scale. Over time, I’ve learnt not to answer the “expected CTC” question, no matter how much they pressure me. It’s the company that should disclose the CTC. Interviews should be about figuring out how both sides can add value for each other. That’s how you build respect. Don’t ruin it by using the power imbalance to try cheap tricks. If your boss ordered you to do so, gather data to show your boss how it’s detrimental in the long-run, and how things can be done better. Ignorance, is the main reason that poor practices propagate.
People in the tech world are increasingly becoming aware and speaking up about the pointlessness of telling programmers (especially experienced programmers) to solve tiny programming problems. Just because some big-tech company does it, you don’t have to monkey-see-monkey-do. People have also begun expressing surprise at how the interview process is more difficult than the actual job, and does not even reflect the actual job. Take time to think and re-design the tech interview process. It’s the need of the hour. Surely, companies can go “above and beyond” to induct a new member of their corporate “family”.
- Here’s a similar post by Dr. Stuart, about why you should never consent to a coding test during an interview.
- One from Jonatan Frank too, about how coding tests can be disrespectful.
- Even Karol Tyminski points out how wasteful the process is.
- Gregory Leman has some pointers on Interview Questions for Developers.
- Fernando Doglio on why 4 hour long interviews are wrong.
