I spent three months working full time to get a job. Here’s how it all went down.
This is a long article. If you don’t like reading, here are the highlights:
- Yup, hiring is messy.
- Build empathy for your candidates.
- I got a job.
And, since we are all so data driven, here are some metrics that may wow you:
- Number of companies
- Number of people
- Hours spent talking
- Hours doing homeworks
If you like reading, please, carry on.
- My Process
- Tension Between Management And Individual Contribution
- The Outcome
- The Aftermath
Most of my career has been as an early employee at startups, a couple of which have gone well, and a couple of which have not. Most recently, I co-founded my own startup. Since I’ve been early and technical and enjoy solving problems across software and management, I’ve done a lot of different things, and my title has bloated to CTO.
After my startup, I took time off to decompress from the stressful experience, enjoy some free time with my wife, celebrate the National Park Service’s centennial anniversary, and read. I thought I would pick up a side project to work on to keep my coding chops tight, but once I got into the hiatus, I realized I wanted to stay completely away from tech for a bit. No reading articles or blogs. I ignored Twitter for most of the time, too. When at the beginning of August I was ready to start looking for a job, I figured the best way to do it was to treat the job search as my full time job. So that’s what I did.
Since I was making this my full time job, I went about it deliberately, as I would my actual full time job. I had not done a proper job search since 2000, and I wanted to talk to lots of different companies and people and to be intentional about my decision. I wanted to be making a career decision, not just finding the next place to work. I started by brushing up my resume and writing down my thoughts about the kind of role I might want. I also talked with a good friend several times early on, to help me make sense of those thoughts. My conclusion, to start, was that I would find a CTO-like role: either be the CTO at a company fresh enough to need my experience or a role at a more established company that would give me responsibility across teams.
I tapped my network, asking for intros to recruiters, VCs, and specific companies, and I was off to the races. I accepted pretty much any intro so that I could get a feel for the different opportunities out there, and because as I talked to more people about what they needed, I could get a better sense of what I wanted. It worked. After a couple weeks of talking about CTO and VPE roles (because those are merged often enough at small companies), I realized I wanted less proper management responsibility and more focus on solving technical problems.
Since I was accepting so many conversations, I needed to keep copious notes and maintain a schedule. I kept a spreadsheet with all of the companies that I wanted to talk to and individual notes for each company or individual who I had a conversation with. My calendar was covered with meetings. Each time I had a meeting, I would record my notes and thoughts so that I could reference them later. If I had follow-up questions, they went in the note.
Before each interview, I researched the people I was going to meet and wrote down questions that I would specifically want to ask them. I kept a list of generic questions and adapted them to the specific people if I did not have a question that was more directly related to the person or company. This meant that at the end of each interview, when I was asked if I had any questions, I’d be prepared to start a good conversation.
A few of my favorite questions that I asked a lot:
- What has surprised you since joining?
- What process or structure would you like to add?
- Think of your best engineer. And now your worst. List the characteristics of each.
- If you have found that a chosen technology does not actually meet the needs of the company, what happens?
In a normal article about interviewing, this is the section that would tell you how much practice the author did and how it really worked to her advantage. Wish I could write the same thing. The truth is that I did not practice at all. I should have though. On one hand, I know that I would not necessarily have been able to solve some of the live coding problems any faster, because I require a decent amount of thought before writing code. But on the other hand, practicing these exact kinds of problems would have given me more confidence to flub my way through even when I wanted more time to think.
Going through design presentations would have been very valuable, too. It would have given me confidence to break down a problem, talk about it in person, handle being pushed off course, etc. Maybe I still would have been flustered by the interviewer’s personality or the specific question, but I don’t think the practice would have hurt at all.
Let that be a lesson for next time.
On the other hand, I did write down a good number of stories that would be decent answers to behavioral interview questions. In thinking about the questions I might need to answer, I developed the vocabulary I could use to speak about how I solve problems and approach work (ie, I honed my pitch). This was extremely valuable, especially when speaking with the hiring managers, product managers, and founders.
As part of my process, I wanted to be able to evaluate all of the possible opportunities in isolation from any discussion about compensation. To get there, I needed the companies that were interested in making an offer to tell me that without giving me an offer and potentially asking for a definitive answer in a short period of time. In other words, I needed them to say “yes” and no more. I also wanted to know which companies were not interested in extending an offer so that I could stop thinking about them – I would discard the “noes” from my brain. The plan was to collect the “yeses,” take time to evaluate the opportunities, and then ask for proper offers.
I did not do this to help with negotiation, though it certainly had that benefit to some degree. If you want to read more about how to negotiate, I’d suggest reading Haseeb Quereshi’s article “How Not To Bomb Your Offer Negotiation.” The reason I did this was because I wanted to get all of the interview stress out of the way and line up all potential jobs in order to be able to think clearly about the roles and companies all at once. I needed to know what opportunities were available without having to prematurely decline an offer just because the timing was bad.
The key that made this work was being very upfront about this process with the recruiters. I explained what I wanted to do, and why, and everyone was very kind and flexible with me. I think that if I had not made it clear that I wanted to do this (or if the job market weren’t so frothy for job seekers) that it would have been difficult to back in to once a company got to the point of being ready with an offer.
After a few weeks into the process, I adjusted my story to aim for higher-level IC roles, something with a title like “architect” or “principal engineer.” I wasn’t hung up on the title itself, but using the title was a good way to prime a conversation about the role I wanted. The nice thing about looking for an IC role was that it fits with my belief that being a software engineer can be a long-term career. I’m getting up there in years, and I wanted to determine if I was going to be pushed towards management now, or if I could continue a career as an individual contributor.
As I explained to people the role I wanted, I found that I needed to justify not wanting to be a manager. I believe that management and software engineering are two vastly different skill sets, and they should be treated as such. People who want to be good managers should be students of the art of management. Unlike writing software, you cannot practice being a manager in isolation. You have to make mistakes that will negatively affect people’s lives, to a certain extent, in order to become a better manager. It is a hard job, and you must be fully dedicated to learning how to do it well if you want to do it at all. Right now, I am more interested in continuing to be a student of the art of engineering.
I ended up talking to 54 companies, ran through the full interview process with 14, was properly rejected 5 times, and received 6 offers.
I accepted 1 offer.
Hiring is a huge mess. Pretty much everyone in the industry has come to this same conclusion and talked about how they are trying to make it better. Google has released research that shows how much of a huge mess it is. I thought I had a pretty good handle on how messed up it was and thought I had some ideas about how it was getting better. Turns out, it isn’t any better, even though everyone talks about wanting it to be. Yes, I had interviews that felt cooperative and candid, but I had more interviews that were power struggles and opaque.
Overall, I found the process to be
dehumanizing, stressful, chaotic, inaccurate, opaque
Even the companies that had written beautifully typeset, well-meaning posts on Medium about how progressive and inclusive their process is don’t do it well. And it isn’t their fault entirely. They do have good intentions. But they aren’t executing to that plan. They haven’t trained everyone involved in the hiring process to bring that mindset to all interactions with the candidates. So your mileage may vary: it comes down to who the recruiter is you get matched with, who is on the interview loop that day, and how your day is going personally.
My best, though most unrealistic, suggestion to make this process better is to require everyone who is part of the hiring process at your company to go through the interview process somewhere else regularly. Of course, there is serious risk to this, but it is absolutely the best way to understand just how broken the system is, and it forces you to develop empathy (assuming you aren’t a sociopath).
You could try to simulate this in house. When I was training our interview panels at Opower, I had them fake interview me and then gave feedback. It isn’t the same experience, because there is not as much riding on it, but at least it will put you in the hot seat for a bit. And it has the added benefit of helping your interviewers improve at interviewing.
Being rejected by a company feels bad. I knew I blew one of the four in-person interviews at one company, but when I got that dreaded “I would like to update you on the decision that the team has come to” email, my heart still sunk. A friend put it quite nicely when he said, “It’s insane to think that they have such problems that you couldn’t help them because you didn’t come up with a design in 30 minutes.” Quite true. But if my resume didn’t look right or I blew an interview, then I don’t get the job. Rarely are there second chances. The one time I got a second chance, I nailed the interview and still didn’t get the job. What? That one was particularly painful.
While I do have some ideas of how to improve the process, I do not have a suggested perfect hiring process. Partially because it is impossible to craft a single process that will work for all roles, for all candidates, for all companies. We need to balance being unbiased and impartial with respecting the experience and background of the candidate. It is relatively easy to do in one-off situations but very hard to do at scale. In response to their research on interviewing and hiring, Google has released a guide to structured interviewing. It is worth taking a look at and evaluating if you think it will work well for your company. Hint: probably so.
The trick (and it really is a trick, because if you can pull it off, it will be the equivalent of magic in comparison to everything else we do) is to be empathetic to the candidate. Like most of our problems in the tech sector, we cannot just solve them with more technology and data. This one is a human problem, and we need to solve it by being more human.
So, while I won’t craft the perfect interview process, I do have some tactical suggestions to help make the existing ones better. And, please understand, I have made pretty much all of the mistakes as a hiring manager and interviewer that I am highlighting below. So don’t read this as a “holier than thou” indictment. It is only by having sat on both sides of the table that I am able to see these lessons clearly now.
A homework assignment lets a candidate do work in her own environment, both technically and socially. We talk about letting candidates bring their own laptop in and how that is so much better than writing code on a whiteboard. In the word of our president-elect: WRONG. Just having your own computer in front of you to type on does not remove the unnatural elements of the environment like having one or two people staring over your shoulder as you try to wrap your head around a problem you have never seen before in a very short time. With a homework assignment that is not timed, you let the candidate do her best possible work in her ideal environment, and yes, while a work environment is sometimes chaotic, when she needs to get her work done, she is going to make her environment as perfect as possible. If you ask for her best work and give her space to do it, you may actually find out how she would do work for your company. I was fairly disgusted by the code I wrote in live coding interviews, but I was very proud of the code I wrote for homework assignments. Wouldn’t you prefer to see the work product that the candidate was not disgusted by?
If you ask for her best work and give her space to do it, you may actually find out how she would do work for your company.
Now that you have this beautifully crafted solution, you absolutely better talk about it with the candidate. She just spent her own time (likely after work or on the weekends) showing you her best. You owe it to her to talk about it. And you owe it to yourself, too. Because talking about the candidate’s homework is going to give you great insight into how she thinks about problems, crafts solutions, defines abstractions, and tests. If you prompt her to include it, you may also see her entire commit log, which would give you a view into her process, too. Then, after you have talked about how it exists now, ask her to change it. Make the problem slightly more complicated. Add a new feature. Fix a bug you found. Go through this process in person with her, and you will see all of the stuff you wanted to see asking her to write a depth-first graph traversal algorithm on the whiteboard. You will also see if she thought through potential extension points to the problem and left them open or closed.
The typical objection I hear about giving homeworks is that a candidate working a full time job would not want to expend the effort to do the work. And for passive candidates (i.e., those who are not actively looking for a job), that goes double. But I contend that asking someone to take a sick day or PTO to come to your office for six hours without a strong degree of confidence by both parties that there will be a good fit is just as bad as asking the candidate to spend some time after work on an assignment. Yes, I realize that people with full time jobs sometimes don’t have the time outside of work to essentially do more work, and you need to be aware of that and have an alternative game plan. This is one of those parts of hiring that makes the process so complex and where you should consider being flexible for candidates who you think are truly strong matches. I am not dictating that homework must be the first part of the process. But it should definitely be the centerpiece of the technical evaluation.
Enough with the graph traversal problems. I was given six different graph traversal problems over the course of this process. In the prior 17 years of professional experience, I have never needed to write a graph traversal algorithm. That doesn’t mean I don’t know what it is, how they work, or how to write them. All it means is that it is not a very realistic simulation of the real work I would be doing.
Caveat: if you really do need people who specialize in graph traversal algorithms, then you should definitely be interviewing for that.
That said, there were a couple cases where I think the graph traversal was justified in the interview process. There were two times that traversing a graph was part of a larger “real world” problem and not the sole problem to solve. Ok. And there was one time when I was asked to write a bit of ETL that the company had actually written. Ok. But I bet the guy who wrote the code didn’t have to do it in 45 minutes having never seen the data before and with another person watching over him. Just sayin’. Simulate the real world. You want me to write an ETL process that is the kind of thing you do on a daily basis? Cool. Give me a few hours to sit on my own and think it through. I may even come back with a solution better than the one you came up with.
During one architecture and design interview, I was asked to design the system for the company’s exact product. The company is a wildly successful “unicorn” that has been around for several years. The interviewer asked me to take the 35 minutes I had left in the timeslot to come up with a design that would be ready to build. Here is my issue with this question:
- The interviewer has so much context on what the real system is and why those decisions were made that he has to actively work against internal biases in order to assess my fresh outsider’s perspective.
- Setting the expectation that we would be ready to build is absurd and tips the interview out of favor, putting unnecessary pressure on me as a candidate. Either explicitly letting it be open ended or helping me navigate to the topics you want to cover in the short time we have would have made it a much more valuable assessment.
The issue is not as much with solving a company’s real problems as it is with the interviewer having much more context on the problem and having thought about it considerably more than the me. So, it rears its head even when the questions are more abstract like implementing Conway’s Game of Life or building a circular queue. In all three of these cases, I felt like the interviewer had made a leap of insight and was hoping or expecting to me to make that same insight. When I failed to make the insight, I failed the interview.
That is the trap. The interviewer must remember that the candidate has been thinking about the problem in front of her for practically no time compared to the amount of time the interviewer has. When the interviewer forgets that, all candidates look dumb and unable to get things done.
I’m not suggesting you give the candidates the questions ahead of time, but you can certainly do more to prepare the candidates for the types of interviews you conduct. One recruiter wrote a few paragraphs about what they expect during the interview process and included some tips about how to “perform well” in the interviews. He also gave me this list of resources before I came in:
- System design interview
- System design interview questions
- System Design
- How do I prepare to answer design questions in a technical interview
- How to ace a system design interview
It is not a list I could not have found myself, but it was reassuring that he wanted me to do my best work in this interview and was willing to help me get there.
Another recruiter spelled out in detail who I would be talking to, their roles at the company, the kinds of questions they may ask me, and the topics that they might be best equipped to talk about that may interest me. Super helpful.
Contrast that to the experience when I explicitly asked a recruiter if there was anything she could tell me I should know or prepare beforehand and she told me that the team wanted to tell me more about the role and get to know me. Turns out that the last interviewer also wanted to talk about the details of my homework – my homework that I had not looked at in over a month. Wonder how well I did in that one?
This goes for recruiters as well as for the people doing the interviewing.
To the interviewers, remember that the interview should be a collaborative process. You should want the candidate to do well, because when you hire someone, you have less recruiting to do! This is not a time to try to show up the candidate. You already have the job, so you don’t need to prove you are smart or that you have relevant experience. Yes, you can push on answers the candidate gives and throw curve balls into questions to see how she reacts, but do not be adversarial about it. That is the wrong attitude for this process.
To the recruiters, show that you are interested in the candidate’s success. Part of this is helping them to prepare, as I discussed above. But just being generally supportive and kind is really helpful as well. Understand that this process is stressful, and having someone at the company who is really interested in seeing the candidate succeed can help ease some of that stress. At one company I never met the recruiter I was working with in person, even though I went to the office four times. At another company, I met three or four recruiters, all of whom spent time chatting with me and showing me around the office as I waited for the first interviewer to arrive. It was very civilized.
At Opower, we called this a scorecard. We wrote out the qualities and skills we were looking for, assigned interviewers to assess them, and made sure that they were covered well. It was never perfect, but it was pretty good. I saw one company do incredibly well in this regard on this go ‘round. Each of the four in-person interviews was completely thought out and almost scripted. It felt a little stilted at times, but I appreciated that they were doing a full assessment of me, and because I had different experiences with each session, I better understood them.
In contrast, I had one company ask me pretty much the same question twice. They were both graph traversal live coding questions. They learned nothing new in that second interview.
Even worse, I had one guy come into the interview, admit he had not had time to read my resume, and ponder aloud “Hmm, what can I ask you.” He then proceeded to ask insulting questions like “Do you have experience with relational databases?” and “Have you worked on software teams before?” Use that game plan to prepare for the interviews and be sure you get out of them what you need to make a good decision.
This is probably a much larger topic beyond just the hiring process, but I felt it acutely enough to include it here. I heard from many companies something along the lines of “we have a team of really smart engineers, great engineers, but they are all pretty junior, and we need some more maturity on the team.” Cool! I’d be great for that. I’m somewhat smart and really mature :) Unfortunately, a few times I felt the immaturity, and it was horribly unattractive. Without getting into the weeds, I’ll just say that if you want to hire more mature candidates, figure out a process that will work well for people with lots of experience and prepare your less mature interview team for that process.
I am a punctual guy. In fact, I value being on time so much that I almost always arrive early. One company was amazingly punctual. The four 45 minute interviews started and ended like, well, clockwork. It was impressive. Sadly, in 45 minutes it was nearly impossible for me to ask the questions I wanted to ask – the questions I needed to hear answers to in order for me to evaluate whether I’d want to work at the company. So, it was great that no time was wasted, but I would have liked 15 more minutes with each interviewer to actually assess the company. Remember: interviewing is a two-way street. The candidate is judging you as much as you are judging the candidate.
Most companies do not offer any feedback, mostly because companies are afraid that rejected candidates will lash out with lawsuits. Given our litigious society and risk aversion, I don’t necessarily blame them. Add to that the fact that it is really hard to give candid feedback without having a supportive environment in which to give it, I understand why companies would not want to give feedback. That’s fine.
But, I had one recruiter who opened the possibility of feedback. She said that the company would want to keep open the potential of me trying again in a few months or a year. I asked for feedback that would help me as a candidate at other companies. She said she would go back to the team to ask for feedback that she could pass along. Maybe this was her first rodeo. After a week of waiting for a response and pinging her again, I finally got the answer: “Unfortunately, there isn’t any information I can provide on my end.” Maybe she really did try. Maybe there was hope that the team would make an exception for me, just this once. But I doubt it.
These are mostly notes for myself for next time. Free advice always comes with the caveat that your mileage may vary. In fact, this advice may not make any sense for you and your situation at all. So take it with the grain of salt you paid for it.
I already mentioned this one above. For technical interviews, practice doing technical work. For non-technical interviews, practice talking about yourself; surfacing the uncomfortable parts of your past and crafting them into stories of growth. Even practice the answers to all of the standard questions you would never expect to get as a really experienced candidate, like “Where do you see yourself in five years?” Never hurts to have these kind of answers nicely polished.
Practice deflecting questions you don’t want to or cannot answer with blunt honesty. This is one of my hardest ones, and one of many reasons I will never be a successful politician. When I am asked a question, I answer it. Straight up. “Do you know Python?” “No.” Of course, the full answer is, “No, but I know other dynamically typed languages, other object-oriented languages, and other functional languages, and I am a quick study. While I personally believe that it takes quite a long time to truly know a language, because there is always a larger ecosystem, best practices, idiosyncrasies, and whatnot, I do think I could come up to speed and be productive in a reasonably short amount of time.” Damn. Why did I just say “no.”
Do lots of first round informational interviews, but nothing more with any company. Then narrow down the list of companies to have further conversations with. Take some top choices and do the full interview process. I started having conversations with people, and those naturally flowed into more conversations and then full interview processes, and before I knew it, I was deep in the interview process with more companies than I could handle. Instead I would gate the full interview process until I knew exactly which companies I wanted to proceed with.
Start engaging with the larger companies first. They typically move more slowly, sometimes requiring several weeks just to get your resume through the applicant tracking system. I thought I was making good progress at one company and was ready to start the real process. After a couple weeks of silence, I found out that the role I had been talked to about hadn’t been officially opened yet and that I’d have to wait for the budgeting process to complete. Unfortunately, it was too late in my process to wait.
Use the “collect the ‘yeses’” process. That is described above, and I think it worked really well because I was upfront with everyone about it from the start.
I got a job. It is a different role from one I have had before, but not so different that I am not confident I will be able to grow into it. It is with a larger company than I have ever joined, working with a scale of users and data that I have not worked before. And best of all, I will be working with a team of people who I respect and expect to learn a lot from. This will be a solid step in my career, giving me the opportunity to go deeper with technology while at the same time beefing up my softer skills.
I am lucky to be in an industry that has a lot of demand for my skills, and I do not take that for granted. The process was stressful and took a long time, but that was because I had so much opportunity.
I am thankful for sure.
This is a slight exaggeration. After thinking about it for a while, I came up with one actual scenario when I wrote something like graph traversal code. It was pretty low level code that I was writing as part of a framework that other engineers would use in our ETL process. So, one time in 17 years of professional development work. ↩
I really wish I had a good suggestion on to help the interviewers remember to change their perspective, lose their biases, and be empathetic to the candidate. ↩
The infographic shows all of the conversations I had during my job search.
Each circle, square, and diamond represents one conversation, and the edges between the nodes show how one conversation led to the next.
Days flow from the top down, and in each row, the conversations are positioned left to right from the beginning of the day to the end.
Different colors represent different companies.
- Hover over the conversations to see more details about them.
- Click on conversations or paths to see how they came about.
- Go wild!
Media for conversations
- Video call
- In person
Outcomes of conversations
- Offer accepted
- Offer declined
Types of conversations
People I talked to
- Click on a company bar to see it highlighted in the diagram above.