Job interviews can really suck, but I don’t dread interviewing nearly as much as I used to. This is the third post in a series about how I manage my interview processes to achieve that. Maybe some of my methods will work for you, too.
In the previous post we talked about my success metrics for interviews that put me in control of whether or not it’s successful—not my interviewers.
Here’s an excerpt from the conclusion of that piece to refresh your memory:
I use my own success metrics about whether the interview was worth my time…
- Did I meet someone?
- Did I learn something?
…they help me feel like the interview was worthwhile and helpful to my career even if the company doesn’t move me forward.
Today we’ll talk about how I limit my time in interviews to the companies that will allow me to achieve those goals. Before I’m worried about my goals, though, I first want to make sure I avoid toxic interview experiences.
First, I try to filter out companies with an unattractive Flip.
There’s a characteristic of the interview process that I call “the Flip.” Here’s how it works: first, the recruiter makes the applicant feel wanted and valued. In many cases, the recruiter reaches out to the applicant in the first place. Then, at some point after that, the experience flips into testing mode instead of selling mode. That is, even though programmers are in demand, many interviewers are out here doing their best to make it feel like that’s not true.
I characterize companies on their Flip:
- How early in the interview process does it happen?
- How extreme is it?
- Do the interviewers make any effort at all to sell the candidate on the company, or do they see their role solely as evaluating the candidate?
- To what degree do interviewers try to equate “accepted at this company” with “good enough” for this company, “good enough” in general, or even “as good as themselves?”
- To what degree do interviewers attempt to convince candidates that they aren’t “good enough” or are somehow unworthy?
If all of that sounds unfamiliar and horrifying to you, I congratulate you on having had an unusually positive set of interview experiences.
Technologists stay in jobs they don’t like because they dread the grueling friction of the interview process. The above represents some of the worst friction. In some cases, the experience becomes actively toxic. It especially happens to folks from underrepresented groups in tech, of course.
How do I rule out these companies?
1. I check ahead of time with my network.
I talked a bit about this in the first post of the series: I rely almost exclusively on referrals from friends, who can let me know how the interview process at this company will be.
2. I signal to recruiters that I don’t see myself as a commodity.
I need to put a warning on this tip: if I let recruiters treat me as a commodity, they treat me as a commodity. However, if I do the signaling I’m about to describe, recruiters at companies with an unattractive flip don’t treat me better: instead, they stop reaching out to me altogether. This is fine with me because I have better things to do than spend time in toxic interview processes. This is not a good technique for you if you need to take any job you can get right now.
I have a few e-mail scripts ready to go that help me filter out companies that I suspect of treating applicants as commodities.
Script #1: The Commodity Script
When a recruiter sends me a form e-mail, I’ll often send back my own form e-mail:
Subject: Thanks for Reaching Out About a Position
Hey, thanks for reaching out! And thanks for considering me for this position.
This post explains who I am, what I can do, and what I’m looking for in a prospective employer. It also explains how a company gets precedence over other companies in my interview process.
Before we schedule a call, I’d like to know how your company fares on:
- The “Questions I’m Going to Ask You” section of that post.
- The interview process, as described in that post.
Depending on the answers to those questions, it might make sense to chat. And if it doesn’t, I can still pass your answers along to my network in case anyone there is interested.
I have had a recruiter respond to this e-mail in the manner that it requests exactly one time. So, like I said, not the approach to take unless you are only looking for the perfect thing.
Script #2: The Script for Companies with Horrible Track Records
I have a special script that I send to Amazon, Facebook, Uber, and similar: companies notorious for ethical violations or gross workplace misconduct. Interestingly, the following e-mail gets a lot more response from recruiters. I don’t expect most of these companies to be the right fit for me. Instead, my aim is to make it visible that their unethical behavior affects their ability to recruit. I think many companies don’t really care about their impact on anyone else until it’s hitting them in the checkbook. Here’s the script:
Subject: Thanks for Reaching Out About a Position
Sure, let’s chat.
As I imagine you’re aware, [COMPANY] recently made the news for [EVENT/BEHAVIOR].
I regularly speak out against that kind of behavior from companies. If I were to take a job at [COMPANY], I’d be obligated to explain that choice to my platform. I want to make sure I have a good explanation to offer.
So: what makes me an attractive candidate to [COMPANY]? Presumably it’s more than just the fact that I have Pivotal on my resume: lots of people have that.
And what, if any, are [COMPANY]’s plans for reversing both their impact and the public perception of their impact in these areas?
3. If the company insists on giving me a code challenge, I insist on learning from it.
If I have a good initial experience with a company and we move into the next phase of the interview process, I am usually asked to complete some kind of code challenge. I have done a whole lot of these, and I’m getting pretty tired of needing to prove to companies that I, the writer of this blog, can code. Maybe that’s wrong of me. I’m not especially sorry.
But if I have to do it, it better be enjoyable and educational for me. Here are the rules that I give to recruiters about code challenges:
I know you need to check my technical chops.
To that end, I have several open-source examples of my work, including:
- This end-to-end data science cycle
- This in-memory database implemented in Ruby
- This complete example of proxy models in Python (on Django)
- This React Native App that searches for unsplash images
- This Android app that collects and caches data stored in a list
- This README directory of the iOS apps that I write for teaching iOS development, as well as this resource containing my slides and curriculum
- Hundreds of blog posts, with a sidebar that allows you to filter the posts by programming language
You can assume that this is the floor of my ability in these specific stacks—since I might have leveled up since I wrote what you see here :).
Companies for whom one of my existing repos will suffice as a code challenge get precedence over companies that need me to do their specific code challenge.
Chelsea, we need you to do our take-home code challenge specifically.
I understand: sometimes, the above examples don’t cover what you need to know about my contribution capacity.
Here’s the thing about take-home challenges: you’re asking candidates to do what they do for money (write code), for you, for free. So it’s important to put some thought into how to make that worthwhile. Here’s how I make sure you’ve put in that thought:
- Your code challenge lines up with the job you’re hiring me to do. I have seen cases where the code challenge is not relevant to the skills I need: for example, a parallel programming challenge for a data science position, or a binary tree from scratch for a web application development position. This is a big red flag.
- Your code challenge is interesting. The challenge has to support me growing my skills. I want to be able to learn something from your challenge, just like you learn something about me from your challenge.
- The time frame covers multiple programming sessions. I work best when I have time to think between spurts of coding. Also, a time frame that spans sessions is realistic to the job you’re hiring me for, unless you’re hiring me to enter speed hack competitions, which you aren’t.
- We have to agree on at least one of the following: Either I receive actionable, specific, technical feedback on the code I submit, within five business days of submission, regardless of the hiring/moving forward decision, or I am free to publish the body of my submission, in whole or in part, for use in blog posts or teaching.
- Companies that facilitate both of these things get precedence over companies that facilitate one or the other.
- I am not trying to give away your proprietary challenge. I will not publish the text of the challenge itself, nor the name of the company that gave it to me. I will only publish code I wrote, which I own. I keep this clause in here to ensure that I get to further either my own skills or someone else’s skills with the work that I do for you.
I’ll be honest: many recruiters don’t respond to this particularly gracefully, either. But in all the jobs I have taken where I needed to take a code challenge, the code challenge did fulfill these criteria.
I use my own metrics to determine my success in a job interview:
- Did I meet someone?
- Did I learn something?
I also filter companies out of the interview process who lean toward a toxic experience or who seem unlikely to help me fulfill these goals. I do this by characterizing companies on how fast they “flip” from sales mode into testing mode. I ask my network about companies’ interview experiences, and I use form e-mails to signal what I expect with as little recurring emotional labor to myself as possible.
Also, if I am going to invest time in a company’s code challenge, I insist on learning from it. I have spelled out what that entails for reuse, again, to save myself some emotional labor.
These techniques are not useful for getting just any job I can get. But they allow me to ensure that I am only spending time in interviews that will be a productive experience for me.
If you liked this piece, you might also like:
The Behind the Scenes series for how-to’s on various options for advancing your career
This series on socializing big changes at your new (or your old!) workplace
This piece explaining stock options (complete with donuts!)