Interviewing sucks—a lot.

If you’ve ever gone through the rigamarole of a modern developer interview, you know that all too well. Dusting off college textbooks to relearn algorithms and data structures, answering inane questions like how many golf balls fit in a school bus, and, worst of all, whiteboard coding—many companies have turned interviewing into an absolute nightmare. It’s almost as if they enjoy torturing prospective employees.

First impressions matter, and the first impression of your employer shouldn’t be that they are sadistic.

At MartianCraft, we’ve spent 20 years building an interview system that consistently produces real results. I often tell people that the most valuable intellectual property at our tech company isn’t any framework, codebase, library, or algorithm—it’s our hiring system. Not because it’s the hardest or toughest to get through, but because it predicts how developers (and designers) will effectively work in an actual environment, without pissing them off along the way.

We have several steps in our process, most of which are outside the scope of this article. What I want to highlight today is our “take-home test,” the fourth and final step of our interview process. Many companies offer take-home tests these days because they are a great way to see how a potential hire actually codes. The problem is, these tests can take hours, and if someone is interviewing with several companies, then completing these tests almost becomes a full-time job. Real talent often is desperate enough to code for free, and rightly so.

We address this issue in several ways:

First, we create a real-world sample project that closely mirrors the challenges you’ll face in the day-to-day work environment at MartianCraft. We ensure the project is clearly a sample; there’s no way any applicant could mistake it for actual project work. If a candidate believes you are using them for free work, they’ll run—and if they don’t, you probably wouldn’t want them on your team anyway.

Second, we intentionally introduce bugs, crashes, performance issues, and even grammatical errors into our program.

Third, we create a list of mock tickets that mirror daily work challenges. Each ticket describes a problem—maybe fixing a crash, implementing new UI or functionality, or improving performance—complete with all the details you’d get from a project manager or stakeholder. Applicants can choose a ticket at their discretion or attempt multiple tickets within our fixed time window.

Fourth, we pay for the work. Despite the fact that we will never use the project for anything besides screening the applicant, we make it clear that we value their time and will compensate them at a very fair rate for their work. This not only encourages them to put in genuine effort but also sets the tone for the entire working relationship with us. We value their time, we don’t expect them to work for free, we honor our commitments, and we believe that they will succeed when given the right tools.

Once the applicant submits their code through version control, several developers on our team review everything they did. Were they able to complete the ticket to specifications? Did they follow instructions? Did they catch other issues like typos while they were at it? We can assess not only how well they solve problems but also their speed and attention to detail.

Our system isn’t perfect, but we’ve refined and tuned it over the last 20 years. We believe we have the absolute best hiring system of any company in the world for evaluating developers. Each of our four interview stages is designed to provide us with specific insights into whether a candidate will be successful with us in the long run.

By respecting the time of everyone who applies to work with MartianCraft, we believe we are setting up a successful relationship from the start. And by paying you to interview, we hope to show you that we live up to our values—and to take some of the suck out of the process.