interview-api helps promote healthy software hiring practices by providing candidates an opportunity to showcase real-world skills.
Tech thought-leaders including Adrianne Jeffries, Anil Dash, David Heinemeier Hansson, Jeff Atwood, Jon Evans, Julie Bort, Max Howell, Quincy Larson, projects like Hiring with Whiteboards and They Whiteboarded Me, and companies like Foursquare, Slack, Square, and WebPT.
If you are a company looking for quality software engineers, whiteboard interviews are a thing of the past.
-
Provide a machine for your interviewee to code with, or allow them to use their own.
-
Don't tell them what the API does, just give them
https://api.cadams.io/v1/and some overall direction (see below) and let them build something awesome!
-
Provide a machine for your interviewee to code with, or allow them to use their own (must have Docker installed).
-
Instruct them to run the command:
docker run -d --name interview-api -p 3000:3000 chaseadams/interview-api -
Don't tell them what the API does, just give them some overall direction (see below) and let them build something awesome!
Find a time that works right for your needs. Maybe you want to see well-written code with unit tests - that will take much longer than an hour. Perhaps you care less about the written code and more about the design, and an hour is plenty of time.
The recommended time is three hours, to give the candidate enough time to research the interview-api, work on a solution, and implement a rough draft of it. However, depending on the role, this may be too little or too much time.
-
Port: If this project in Docker, there is no need to tell the candidate what port to use to access the API - it is in the command you give them.
-
Path: The candidate should be able to find out what URL the real API information is under. This can be done either by using
docker execto get to the code in the Dockerfile, or by finding the interview-api repository. Hence the twist! There are no Swagger docs.
The goal of this project is to get rid of unnecessary impediments in the interview process - don't add any with a restriction of IDE, OS, or if you are bold, technologies. Any good programmer can learn those in time - what makes them stand out is the ability to design/build something awesome.
You're going to have these if you're not careful. Once word spreads you use an open-source project and let developers write whatever they want, someone will come in with a pre-baked solution and ace the challenge.
Providing an original, randomized alteration to your instructions is key. Some examples of good guidelines are (please do not use these):
Interviewer: Please write an API (in any language) which consumes the interview-api Docker container and gracefully handles any upstream intermittent failures.
There is intentionally opinion in this - what does "gracefully" mean to them? Does that mean retry with backoff, or does it mean transforming the error into something more meaningful? There is merit to both, depending on how the candidate imagined the usage of it.
Interviewer: Please create a UI (in any language) which uses the interview-api Docker container and displays a rating system using any characteristic(s) in the JSON payload.
Candidates have the freedom to build however/whatever they want, given the loose constraint that it must be a system which allows users to rate the startups. It could be an Amazon-flavored system, something more Tinder-inspired, or any novel idea.
Interviewer: Please create an API (in any language) which acts as a proxy for the interview-api Docker container and provides application-level caching.
This lets candidates improve upon the (intentionally flawed) interview-api and create something better. It provides an opportunity for them to showcase the areas they think need to be fixed.
The interview-api is open-sourced software licensed under the MIT license.