My best developer interview experience

There are many less-than-ideal practices when it comes to interviewing software developers. Some people give whiteboard interviews, which treat your craft like trivia and put you spot. Others provide you with take-home projects that can seem like free labor. Developers looking for work don’t have time to spend 5-10 hours working on a project that only one company will see. In the worst cases, candidates write code, and then the interviewing company uses it in production without compensation. 

I read frustration online, but I don’t see a lot of positive experiences. I wanted to share the best interview experience I’ve had, as I feel it could be a model for companies to both accurately gauge developer’s skills while treating them fairly.

Step 1: Minimum Viable Contract-to-Hire

After an initial interview, the company offered a small project. It didn’t require any development environment other than a static HTML page. The estimated time for the effort was one hour, and the elapsed time for completion was three days. Within this timeframe, I could complete the work without pressure while still showing that I could stick to deadlines.

They paid me $100 for this.

The company understood that developers are busy and should deserve compensation for work. The requirements were clear and overly specific. It was more akin to a hack you would in place for one ornery customer than production-ready code.

I was freelancing at this time and considered mass applying to jobs to land several tiny gigs.

Step 2: On to the written portion of the exam

The second part of the assignment was writing a 2-3 paragraph essay about how I would approach generalizing the feature and turning it into extendable, usable production code. In addition to testing that I could think about writing quality code and software architecture, this part also gave me a chance to display my writing and communication skills. Writing a clear summary of an idea is closer to what you’ll be doing at your job than a coding exercise written with a marker.

The result

While I didn’t get the job, I left feeling great about the people, the company, and the interviewing experience. I think one reason we struggle with interview processes is that unlike other parts of working in software, its much less open. I hope that by sharing this experience, I give some other companies some ideas on how to improve their processes.