I've said this before, but I'll share it here. This is my current interview process for any front end dev, regardless of level, including the thinking that goes into it. The whole thing is designed to take 2 hours or less. Note: We provide either a physical laptop if onsite, or an AWS box pre-set up for this.
1. Here's a project with a back end API server, it's a repository already cloned to disk, and includes a README.md with very detailed (local) deployment instructions, that one can copy+paste.
Thinking: Validates the individual's ability to read, and synthesise
2. Run the API server - this in turn provides a swagger API, that allows users to see the available APIs in their browser, and instructions to do so. The machine has various chrome plugins, Postman, curl, etc pre-installed.
Thinking: Validates curiosity, and basic understanding of the modern(ish) web.
3. The candidate is to create a new project (framework of their choosing). They have the time of their choosing to implement an impossible to complete task (which we share). They have to create <something> that can trigger various APIs to insert, update, and remove data from a database. We provide the sample data in text files such that copy+paste is possible.
Thinking: Validates if and how they reach out for assistance. Helps us understand where the candidate likes to spend the time of their choosing while working on a solution. Encourages a conversation about difficulties, frustrations, what could have gone better, and feedback.
This entire process is designed to ensure that we actively interview the candidate with something "real". It allows us to understand the real level of a candidate based on their efforts (i.e write tests, don't write tests). This is not perfect - but it's the best we could get. I'd love feedback.
To put on a devil's advocate hat: This is a great interview for someone whose job will be to create basic CRUD web/mobile apps.
And there's nothing wrong with that! 90 (99?) of the software the world needs are basic CRUD web/mobile apps. Hell, for probably 60% of that, a basic no-frills CRUD app would be an improvement!
But HackerNews measures it's baseline of the tech industry against "BigTech". That's more than FAANG, that's now also the 500+ unicorns imitating FAANG.
All these unicorns don't get to where they are by building CRUD Apps - They're Changing The World. (facetious)
And changing the world (serious now) requires not hiring engineers who can build CRUD apps with a database, but engineers who could build the database, the next Swagger, etc.
The bad thing about this is that they (BigTech) can afford to hire the next Edison and have him build CRUD apps in 60h shifts trying to pass performance reviews... And even get away with it financially (for a time at least).
I'll be blunt: your hiring process sounds very similar to what this article is trying to ridicule.
If I was handed someone else's machine preinstalled with a load of tools that you assume I know how to use, I'd probably excuse myself from your interview. What if I use a different keyboard layout? What if I don't use a Mac/Windows? What if I've never used Swagger?
Unless you explicitly highlight to a candidate how 3 is impossible, you are excluding candidates who would do what you want in a real job, but not in an interview setting.
When I was younger, I was always stumped by "trivial" questions, as in why would someone ask me a question with an obvious answer (though my pool of "obvious" answers was pretty large, so I had to tone down those expectations as well)? I've learned to consider all questions in the simplest way possible, but my brain simply glosses over those otherwise, and especially in a test setting, I might look to see if I am missing something ("what's the caveat?").
Curiously, I also do pretty good in leetcode style questions, but I think people are usually taken aback by the number of things I consider simple (I appear to not know shit simply because I avoid talking in big words ;)).
While I applaud your effort in keeping the process simple and "real", keep in mind that nothing beats saying explicitly what you are after with each stage: most people in "interview mode" think differently from "get stuff done mode".
> Unless you explicitly highlight to a candidate how 3 is impossible, you are excluding candidates who would do what you want in a real job, but not in an interview setting.
That's exactly what we do. We make it abundantly clear that it's not possible, nor is the expectation such that it happens. We also turn this into a collaboration and pairing role, with times to dive in and out.. pretty much like exactly what this role entails.
This is how we avoid the "take away assignment" or "l33tc0de" problem. We invest in our technical interviews. Similarly - we let candidates know in advance that this is exactly how they take place, and that they're free to use their own equipment if they prefer. The idea is to "simulate" work.
This doesn't replace the need to go deeper. Instead, this eliminates a very specific type of filter, in exchange for getting to know each other, collaborating, and hopefully mutual understanding.
1. Here's a project with a back end API server, it's a repository already cloned to disk, and includes a README.md with very detailed (local) deployment instructions, that one can copy+paste. Thinking: Validates the individual's ability to read, and synthesise
2. Run the API server - this in turn provides a swagger API, that allows users to see the available APIs in their browser, and instructions to do so. The machine has various chrome plugins, Postman, curl, etc pre-installed. Thinking: Validates curiosity, and basic understanding of the modern(ish) web.
3. The candidate is to create a new project (framework of their choosing). They have the time of their choosing to implement an impossible to complete task (which we share). They have to create <something> that can trigger various APIs to insert, update, and remove data from a database. We provide the sample data in text files such that copy+paste is possible. Thinking: Validates if and how they reach out for assistance. Helps us understand where the candidate likes to spend the time of their choosing while working on a solution. Encourages a conversation about difficulties, frustrations, what could have gone better, and feedback.
This entire process is designed to ensure that we actively interview the candidate with something "real". It allows us to understand the real level of a candidate based on their efforts (i.e write tests, don't write tests). This is not perfect - but it's the best we could get. I'd love feedback.