The fundamental problem with the traditional technical interview process is that it is based on a chain of inference that seems reasonable but is in fact deeply flawed. That chain goes something like this:

- Writing code is hard.

- Because writing code is hard, only smart people can do it.

- Therefore we want to hire smart people.

- The best way to find smart people is to design a process that filters out dumb people.

- The best way to filter out dumb people is to ask them hard questions that we know the answer to and see if they also know (or can figure out) the answer.

Hence phone screens, whiteboard coding, coding puzzles, riddles and all the anti-hiring patters that came to light in the last 10 years.

It turns out that these make terrible predictors of the actual ability to code, and one of the most accurate way to get productive developers is to test them on problems that are closely related to their actual future day-to-day responsibilities.

Will your candidate be working on databases? Ask for stored procedures. Will your candidate work on API? Ask about API design?

We made Type12[0] to let companies go beyond riddles and brain-teasers when testing candidates but actually putting them in their day-to-day scenarios.

More technically, for each interview, Type12 creates a new (docker instance under hood) sandbox fully configured with languages (Python, JS, Ruby, Java, Scala, etc) frameworks (Django, Flask, Ruby on Rails, Node, Spring, etc), databases (MongoDB, Redis, MySQL, PostgreSQL, etc) and other technologies (Amazon S3, Amazon DynamoDB, etc) of your choice.