Let's say I want to hire someone to write automated Cypress end-to-end tests. Here is what I do:
- Write a job description with minimal corporate boilerplate filler like "team player, excellent communicator, fast-paced environment". I do not care about reading this, and it tells the candidates nothing. Instead, I describe what the person is going to do, what kind of projects they will be working on, and the team. The HR department fights me on this, so it does not always go my way. If I win, the job posting will include the Cypress Skills Ladder. If I lose, we will go over the skills ladder in the first interview. This skills checklist describes what I would love someone in this position to know or planning to learn. It gives the candidate a good idea of what the team needs and what day-to-day is going to be like.
- When the job is posted, I have to go back to HR and ask them to delete "Bachelors of Science or equivalent degree is required" from the minimal job qualifications. Recruiters love inserting college degree requirements everywhere, even in the places where it is completely unnecessary. Something to watch out for. I also check for any other "minimum X years of experience with technology Y". I had cases where the job posting had "minimum five years of Cypress experience", which only a few people in Cypress.io had at that moment 😆
- During my first interview with you, I just want to chat about what you have done and know following the ... published skills list. I share my screen and start asking about topics and checking the box if yes. Each topic becomes a jump-off for discussion. For Cypress skills I use my interactive https://cypress.tips/skills form.
For example, if I asked the candidate "did you organize multiple Cypress tests by topic and feature?" and they said "No, we kept all spec files in one folder", we would then converse about how many tests there were, how did they write them, and if it was easy to find and run a particular test. If the candidate said "yes, we organized our tests using the following approach", we would talk about it. Each topic is not a school test-like "pass/fail", but rather a jump off topic for a friendly chat.
After the interview I would copy / paste the test results into our internal candidate HR profile. I hope from the first interview, the candidate gets a very strong understanding of what day to day skills we are looking for. Which helps in the next step: the homework assignment.
- The homework assignment is your chance to shine as a candidate. Now that you know how I think about testing, and what we would like you to do day-to-day on the job, let's see what you can do. The assignment usually is described as follows:
- take any web application and write end-to-end tests for it
- do not spend more than three hours writing the tests
- take as much time to think about the application and the testing approach (within limits of course, if we do not hear from the candidate in a couple of weeks, we probably decide that you are not interested)
- write a new set of tests, do not merely add one more test to an existing set of tests. We want to see your entire strategy
- The homework assignment review meeting. Once the candidate is done with the assignment, they send us the link to the GitHub repo and we schedule the second interview, usually with several people from my company attending. The purpose of the meeting is to review the tests, ask how they work, why the candidate wrote those specific tests, how they implemented them, etc. This matches closely our day-to-day work discussions and pull request reviews. On our side, we see if the candidate wrote good tests, if their thinking about testing, coding, and designing the solution is what we are looking for. The candidate gets a good idea of kind of questions we ask during code reviews, the people they will be working with, the tools and techniques we use.
After the meeting, all people on the company side meet to give their feedback. We discuss the homework itself, and how the candidate explained their thinking, their code and the testing approach. Would the same approach and code pass our normal pull request review? Does the candidate match or exceed what we are looking for?
Bonus: avoid poisoning the well
The most crucial, important, paramount, whatever-big-word-superlative you want to use, thing to do while hiring is to avoid leaving the candidate with a bad impression of the company. For every person hired, you probably interview and reject 1-10 people. These are people who wanted to work with you at your company X. You are rejecting the people who want to join and work with you, yet now they know they cannot. They might feel sad and angry, especially if they feel the hiring process was unfair. Imagine for every employee you have 1-10 bitter people out there - does this change your hiring approach?
The way I solved this approach at Cypress was two-fold. First, be transparent with the candidate. State the salary range upfront. Talk honestly about the company, how it grew, and what the future looks like in your opinion. If the candidate does not have enough required skills already, no big deal, tell them. Second, respect their effort. For a while, if we rejected a candidate after the homework assignment, we would give the candidate a gift card to thank them for their time. A small nice gesture like this goes a long way towards sweetening the loss, I think. I would rather have 100 people out there remembering my company X for the some gift they got from us, rather than thinking how we unfairly rejected them.
Does it work?
Even the candidates we have not made an offer loved the process. Here is a public statement about our process from a person I have interviewed following the advice above. You be the judge.
Cypress interview kit
To help you interview candidates with Cypress experience, I have created an interview kit based on my Cypress Network Testing Exercises course. The kit includes warm-up questions and small testing assignments to write. From the interview kit you can pick 1-3 questions, give to the candidate to code, and then discuss to see how the candidate understands the tests they just wrote.
See also
Bonus 1: Interview
Recently I discussed the interview process with Nikolay Advolodkin, you can watch the recording here.