The #1 Best Anti-Cheat Interview Question Ever
It’s inevitable.
You interview 23 developers to fill a junior role, and you notice more than one of them pasting not-insignificant amounts of code during their technical interview.
At some point during the months-long interview process, one of those candidates posted that question to Glassdoor’s Interview review section, and someone else was smart and morally compromised enough to post it on Stack OverFlow.
Then all it takes is a developer with even a basic amount of Googling skills to find that question and its answer during the interview and use it for their professional gain.
That can certainly be frustrating as an interviewer – finding the right developer or engineer is hard enough in today’s job market without having candidates misrepresent their skills.
So how do you stop this? What’s the #1 best anti-cheat question?
Maybe the problem isn’t that your interview candidates found the answer on Google. Perhaps it’s that your questions can be answered with Google.
Google-proof your interview
Before you start interviewing, check the internet to see if your question has already been answered.
Typically if you’re asking a standard algorithm question, not only will the answer easily be found, but it’s probably not a good question to begin with.
Algorithm questions don’t test much other than one’s ability to pay attention in computer science classes. It’s an easy way to eliminate great candidates with non-traditional backgrounds because instead of testing their ability to solve an actual business problem, you’re testing their memory of a particular and not-often-used set of skills.
Plus, what’s the point of testing something that most people – even your senior devs and tech leads – will probably need to Google even while on the job?
Unpopular opinion: Googling should be encouraged, as developers of all levels use Google to solve issues other engineers have already encountered.
As a manager, I’m sure you’d rather have your employees look up to see if there is an existing solution to a common problem rather than spend hours (or days) trying to come up with a solution that already exists. They have more important things to spend their time on – like coming up with unique solutions to your business cases.
Make your questions specific to your business
If you’re using a business-specific question, it will be a lot harder for a candidate to find the answer – usually because there is no one correct answer.
Like in a business, there should be collaboration as the candidate works through the question with you. This will give you a better idea of their problem-solving approach and if it’ll be a good fit for your team.
It’s also less likely that someone random will attempt to answer the question even if it does make its way to the internet.
Answering generic algorithm questions benefits everyone, but who wants to spend their spare time solving a problem for a company they’re not going to interview with?
Having candidates solve problems related to your business also gives you a better idea of how they’d actually work. It can show you if they know the domain, bring a unique perspective, or can learn how to adapt to new spaces.
With that said, as we mentioned earlier, sometimes questions just make their way out into the world no matter how unique they are.
We recommend that interviewers rotate and refresh their questions because it’s inevitable that the question will end up on the internet.
Example of a Good Interview Question
Here’s a question we have asked when interviewing engineers at CoderPad. It has them implement a part of a feature of our product called Playback Mode.
First, we give them an overview of the feature and why it’s essential to our business:
During CoderPad interviews, people write code in an editor. After an interview is completed, we let interviewers “play back” the editor state like a video, so they can see the candidate’s coding process over time and reference key parts of the interview.
To implement this, CoderPad tracks editor changes (edits) as text insertions and deletions. During playback, we reconstruct the editor states at each timestamp, and these are called frames.
Then we give a usage example along with the business logic that’s operating behind the scenes:
Editor history:
time=0: “” (Editors start empty.)
t=1: Insert “hello”.
t=2: Change “hello” to “hi!”.
t=3: Insert “, world” before the bang. The editor says “hi, world!”.
We then provide them with example inputs of varying degrees of complexity, in this particular case it’s a JSON object of editor changes. This is followed by an in-depth description of how the feature works.
We’ll offer additional clarifying information as needed, but the important thing is to be as transparent as possible about how the existing code base carries out the necessary business logic.
Lastly, we present them with the task, which represents a task similar to what they’d be doing at CoderPad:
Your task for this Challenge is to implement a function which takes 1 parameter target_timestamp, reads edits from the local file /data/playback_ops.json, and returns 1 string, the frame at that timestamp.
Notice the main thing that makes it harder to cheat:
The candidate has to apply their knowledge to an actual business case rather than memorizing a common trivia question.
Most importantly, questions like this give you insight into how the candidate approaches new challenges and their ability to understand your business. And that’s a much more valuable signal about whether the candidate will be successful on the job than their ability to recall university-level computer science lessons.
ℹ️ Check out our guide for hiring managers on interviewing front-end developers.
The anti-cheat bandaid
We at CoderPad do not philosophically believe in “anti-cheat” tactics. That’s an arms race that only produces temporary winners – and it’s never good to start an interview coming from a place of distrust.
The real solution for this concern is to create an “on the job” style interview, where a single correct answer cannot be easily Googled, and you get an accurate read on the candidate’s capabilities.
If this seems like a monumental task to you, fret not – CoderPad can work with you to help you create questions that are relevant to your business.
We also have additional resources to help you create the best interview experience for you and your candidates:
- CoderPad Interview Best Practices
- Returning to the Office? Don’t Bring These Bad Technical Interview Elements With You
- Improve Front-End Coding Interviews with Mockups
Happy Interviewing!
P.S. If you’re still concerned about your candidates using code from an outside source…
🤔 Before you assume you know a candidate’s intentions when you see them pasting code, ask them about the reasoning behind the pastes and have them clarify what the code does. Interviews should be a conversation, not an interviewer staring silently in judgment at an anxious candidate.
In CoderPad, there are simple ways to see if candidates are writing code from scratch or potentially copying it from an outside source.
If you’re conducting a live interview, you can see them actively coding; if they leave the pad for another screen – say to look up an answer – then their cursor and line number will not be visible to you on the pad.
Additionally, you can quickly see in the playback when text is copied and pasted:
