F*** You, I Quit — Hiring Is Broken
--
Disclaimer: This is a story about my interview experience in the tech industry. No personal names will be used to preserve anonymity. The title refers to the industry as a whole, not to any particular company.
Who am I? My name is Sahat (@EvNowAndForever on Twitter), but you may know me better from my open-source projects and tutorials:
- Hackathon Starter
- Satellizer
- Create a character voting app using React, Node.js, MongoDB and Socket.IO
- Build an Instagram clone with AngularJS, Satellizer, Node.js and MongoDB
- Create a TV Show Tracker using AngularJS, Node.js and MongoDB
I wrote this story to share my tech interview experience during past several months and why I’ve decided to stop looking for a job.
Scroll down to the end for post updates.
October 29, 2015 — a recruiter from Google reached out to me, asking if I would be interested in interviewing with them. Sure, why not. Unfortunately I was busy with personal matters at the time and asked to postpone the interview until January 22, 2016.
January 22, 2016. I am not sure why I even bothered to do this interview. Google is notorious for their interview process, I mean they have books written on how to pass a Google Interview. I don’t remember what the phone screen problem was about — some string manipulation algorithm problem — but it was neither interesting, nor memorable. No, I still didn’t understand the question, even after hanging up the phone. At no point was the interviewer interested in me as a potential candidate, or has asked me anything about my open-source work on GitHub and previous work experience. To be fair, I already knew about Google’s interview process that is optimized for hiring book-smart academic candidates who know their algorithms and data structures cold, so my expectations weren’t very high to begin with. There was a very popular post on Hacker News a while back called
Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off. As much as I hate this style of interview, Google is in a unique position where they can use any hiring practices they want, because for every rejected candidate, they will have a hundred more lined up for an interview.
Fast forward to February 1, 2016 — my first phone screen interview with BigCorp A. There was little to no introduction over the phone, we jump right into a coding exercise on HackerRank. I was asked a few basic JavaScript questions, including prototypal inheritance, ES6, and to write Math.pow() function from scratch. The entire phone interview took about about 1 hour, including some questions at the end.
February 3, 2016 — my second phone screen interview with BigCorp A. Similar to the first phone interview, we jump right into a coding exercise on HackerRank. Again, I was asked some basic JavaScript questions, followed by creating a small React component. Overall, the interview process was fairly smooth so far. After passing two phone interviews, I was invited for an on-site interview.
February 9, 2016. I arrived at BigCorp A on time, dressed in business casual. There were three 2-on-1 interview rounds in total. The first round started with introductions, followed by a coding exercise — write a maze solving algorithm. What the fuck?! Seriously? Mind you, this was an interview for a front-end developer position and I am not a recent college graduate anymore. Anyway, that did not go too well, obviously, because it has been a long time since I took an Artificial Intelligence course in college, where I vaguely remember doing some maze solving algorithms. In retrospect, if I had looked at Dijkstra’s shortest path algorithm and breadth-first search one day before my interview, this would have been a trivial problem to solve from memory, but that’s besides the point. I shouldn’t have to rely on an algorithm question lottery to demonstrate my skills and abilities during an interview. Luck and chance should not be part of the tech interview process. The second round was a little more practical, with random questions ranging from JavaScript promises to CSS floats. At no point did it feel like a two-sided conversation between me and the interviewers. It was just a question, after question, after question. The last round was with a senior engineer and a director, which had some coding involved, but mostly it was just a conversational interview. I did not feel like they were prepared for an interview, as they started asking me for questions based on what I said earlier, almost as if they were looking for a reason not to hire me. That’s how it felt in that room, anyhow. At some point during our conversation I casually mentioned Webpack 2 and tree-shaking, which was followed by a question on how would I implement a tree-shaking algorithm. How would I know? If, and when, I need to know how tree-shaking is implemented, I will go look it up. Towards the end, we were kicked out of the conference room and had to relocate to another room. All in all, the on-site interview process took about three and a half hours. By 4:30pm I was so exhausted, thirsty and hungry that I couldn’t wait to get out of there. A few days later, I got an email saying they decided not to proceed further with my interview.
During this time period I was already in the process of talking to multiple recruiters, so instead of cancelling all my interview appointments (which I really wanted to do), I decided to just go with it, although I had less hope now after my BigCorp A interview. A recruiter from BigCorp B reached out to me on February 12, 2016. I sent him my resume, we had a brief chat (didn’t sound like the friendliest recruiter), never heard from him again. If that’s any indication of their work culture, maybe I really dodged a bullet there. And I am not the only one who shared that experience in regards to their poor communication, if Glassdoor reviews are any indication.
February 22, 2016 — a recruiter from BigCorp C reached out to me, asking if I would be interested to interview for a front-end developer position. Alright, why not. The first two phone screen interviews were relatively easy, which I passed without much effort. During both phone interviews I was asked basic JavaScript, Node.js and React questions, nothing on data structures or algorithms.
March 8, 2016 — I arrived at BigCorp C for my on-site technical interview. After waiting for some time in the lobby, I was escorted to one of the conference rooms where I was interviewed by two engineers. After about 10 minutes we jump right into whiteboard problems — implement a breadth-first search (BFS) algorithm. What the fuck?! You’ve got to be shitting me. How many people can actually write BFS on the spot, without preparing for it in advance? Again, I am not a recent college graduate anymore who has breadth-first search memorized, and aren’t my open-source projects and my prior work experience at Yahoo enough to show that I can write code and deliver software into production? I could feel my frustration rise as I am struggling to come up with a solution on a whiteboard: why would they ask me this question, what does breadth-first search has to do with front-end development; I haven’t implemented BFS in years, there is no way I can come up with a solution right here and now; yep, I am definitely not going to pass this interview. I ran out of time before coming up with a working solution. Frankly, I had no desire to put much effort into solving it, because at that point it was nothing more than an insult. It’s like testing your dentist’s skills based on their ability to balance a redox equation using the oxidation number method from their undergraduate chemistry studies. What relevance does it have? Absolutely none. The second round had more practical questions about JavaScript — how event loop works, a question that tests your understanding of asynchronous flow in JavaScript, and last but not least — I had to implement a function that checks if a string could be a palindrome (not if it is a palindrome), as well as its time complexity. There were a few hiccups along the way, but I eventually solved the problem on a whiteboard. At one point I had to explain to one of the interviewers about blocking and non-blocking nature of JavaScript, and why my answer was correct and his premise — wrong. Another interviewer sided with me, saying that my answer was indeed correct. After the second round I was escorted out into the lobby. If I could give it a rating, this was by far the worst, the most frustrating on-site interview experience I have ever had. It’s not just the questions, but interviewers had very little interest in me as a potential candidate from the moment I walked in there, nor have they done any basic research on me, so I might as well be just some random guy from a street walking into their office. Interviews shouldn’t be one-sided battles where a candidate must “prove” themselves in order to get hired.
Well, ironically, that day there was a post on Hacker News — How to Pass a Programming Interview. This particular comment really hits the nail on the head:
“Being a good programmer has a surprisingly small role in passing programming interviews.”
And that just says it all, doesn’t it? I agree that interviews should test candidates on certain basic skills, including (time/space) complexity analysis. But do you really learn anything by asking the candidate if they can recite the time complexity of a moving window average algorithm (as I was asked to do by an interviewer yesterday)? What does the candidate’s ability to code a palindrome checker that can handle punctuation and spaces tell you about their ability to deliver robust, maintainable code?
I don’t have the answer, but I just don’t see how the questions typically asked in programming interviews give you a good picture of the candidate’s actual programming ability. I much prefer “homework” projects, even if they involve me working “for free”, because I feel like they ask for actual programming skills rather than the “guess the algorithm” lottery of phone screens and whiteboard coding.
Another comment (abridged) in the same thread really hits it close to home. It was like a reflection of my interview experience on that day:
“You need to be able to write a BFS cold, and you need to understand how a hash table is implemented.”
While this is great advice, it also demonstrates why people eventually develop interview fatigue over a career. I’m not talking about fatigue from your third interview this week, I mean, I mean fatigue that sets in over decades.
I don’t have an easy solution, since I actually do completely understand why tech employers rely on these exams. But I do think they take a serious toll on the field, and are a major contributing factor to attrition (as well as aversion among people who never go into the field at all). We, as developers, really do have to re-load complicated undergraduate coursework into exam ready memory over, and over, and over.
I’ll finish the way I always do: if you interview like this, that is your choice, and you should feel free do do so — I really mean this. But why then do these employers act mystified that there is a “shortage” of developers? It seems to me that aversion and/or attrition is a very natural outcome for the way we do things in software. “No thanks, I’ll do something else” seems like a very reasonable response to an industry that hires like this.
I know someone who is in a similar position as me, with whom I worked personally and can vouch for being an excellent programmer:
I have to say I’ve had really similar feelings, I’ve been preparing for job interviews by studying all the algorithms things I haven’t looked at for years. And I’ve thought about changing careers a number of times too, just because of how crazy the interview process is. It’s so stressful and so exhausting. I’ve done technical phone interviews almost every day for the past 2 weeks, sometimes companies want 2 technical phone interviews before proceeding, and that’s not including the phone interview with the recruiter! Then I have take-home assignments to do — one of which has taken over 1.5 weeks so far, it’s crazy, and so stressful.
After my interview experience with BigCorp C, I told the external recruiter not to message me again and that I was no longer interested in any further interviews with other companies.
One month earlier, a recruiter from Startup D based out of Brooklyn has reached out to me, praising me for my impressive GitHub contributions and showed a great interest in hiring me (take note BigCorp C). A few weeks later, I had a 1-on-1 meeting with a recruiter at a coffee shop which went pleasantly well. It was a refreshing change of pace after all those shitty corporate interviews. They decided to invite me directly for an on-site interview, without having to do a phone screen first.
March 9, 2016 — Startup D on-site interview. The commute from New Jersey to Startup D office is longer than I expected. I had to leave my house at 8AM to get there on time just before 11AM. Despite its less than ideal location, Startup D has a beautiful office and everyone, with the exception of one person who will not be mentioned, were extremely friendly and a pleasure to talk to. The first round had four interviewers in the room. It was an open-ended discussion about me, my accomplishments, my projects. To be honest, I was caught a little off-guard with this interview format, so my presentation was probably all over the place. If I could do it over, I would definitely spend more time preparing my presentation. The next round had some coding exercises, one of which was to implement a Tic-Tac-Toe game using HTML, CSS and JavaScript. I was able to do it with 10 minutes to spare, although it was probably the most hacky solution I have ever coded. Oh well, under pressure and time limit, especially when people are watching me and I am required to speak out loud, it isn’t that easy to come up with a clean and elegant solution. After my second round I had lunch with a three other engineers, followed by a third interview round — I was left alone in a conference room to solve a problem using any internet resources at my disposal — write a function that parses a large CSV file with text and print the number of occurrences of a sub-string in a given year. It was a straightforward coding exercise for me that I finished with 30 minutes to spare. I spent the remaining time optimizing my solution for better performance. The last round was cancelled because an interviewer was out sick, so we ended the interview a little early.
I did not get an offer. Although my interview experience with Startup D was mostly positive, I really wish companies would be more transparent about their candidate rejection reasons. From this day on, I was even more disappointed — both with myself and tech hiring process — rejection, rejection, rejection. It honestly feels as if I am a complete failure and an unhirable candidate. How is this possible — I have received emails from people all over the world, who praise and give me thanks for the work I’ve done on my open-source projects and tutorials (and I say this as humbly as I can); people who see me as an expert on Hackhands; co-workers, friends and acquaintances from meetups, hackathons, conferences who apparently think I am a decent programmer—but I cannot pass a single tech interview. How? It doesn’t matter anymore. I am getting really tired of doing these interviews. What’s the point? I started to consider that maybe working in tech is not for me, and perhaps I got hired at Yahoo by some miracle or just pure luck.
At this point I was pretty much done with further interviews that haven’t been initiated already and had to reject a few companies, which I would consider under normal circumstances. Failing an interview — it’s not just a loss of precious time that I will never get back— but it takes a huge toll on me personally.
A week earlier, a recruiter from Startup E reached out to me, asking if I would be interested to work there. March 10, 2016 — I had an initial phone conversation with two senior engineers, they gave me a take-home project. I was able to finish it over a weekend. This was one of the rare cases where I actually enjoyed working on it. Afterwards, they invited me for an on-site interview at Startup E. Given my previous interview experiences, I was a little hesitant to do another one. I agreed, but only if I didn’t have to do all rounds at once.
March 21, 2016 — I arrived at Startup E for my on-site interview. I was given an office tour, then went into one of the conference rooms where I had my first round of interviews. The first round went smoothly — we discussed my take-home project, some of my open-source work on GitHub, as well as a coding exercise that involved implementing a modal dialog in HTML, CSS and JavaScript using a laptop and a projector. The second round was with a Director of Engineering — no coding, just a conversation between two people. I realized right there and then — they are looking for someone with a decent amount of experience with video streaming and video encoding technologies, none of which I had. I have never even built a custom HTML5 video player until this take-home interview assignment.
March 23, 2016 — the second part of my Startup E on-site interview. Both rounds were 2-on-1 and were mostly conversational interviews with little to no coding. I prefer these interview formats because they do not put as much stress on a candidate as doing whiteboard problems under a time limit. During my second round, I once again confirmed that they are looking for an experienced engineer with video streaming and related technologies. All in all, if I had to rate my Startup E interview process, I would rate it very highly, a complete opposite of my interview experience with BigCorp C. But one thing I do not understand is — why did they reach out to me in the first place, because nowhere does it say on my resume that I have any experience with video. No offer, because they needed someone with more video experience.
March 30, 2016 — Startup E wanted me to come for another interview with a different team that deals less with video player/video streaming and more with front-end technologies — which is perfect for me! One of their products in particular is essentially a dashboard with charts, similar to what I have previously built at Yahoo for internal use using React and Flux. After considering it for two weeks, I decided to come for another interview after all. I didn’t have anything to lose at that point anyway. If it doesn’t work out, then I will probably just stop— I thought.
April 18, 2016 — the third on-site interview with Startup E. This particular interview took longer than I expected — over 3 hours. The first round was a discussion with another Director of Engineering, no coding was involved. We’ve talked about my past work at Yahoo, my achievements and my GitHub projects. The second round was a 2-on-1 interview with a whiteboard problem. I was asked to write a function findSum(array1, array2, sum) that returns true if two numbers from two sorted arrays add up to a given sum. I was able to solve it with my eyes closed using a double for loop — O(n²) time complexity. For the remaining time I was able to reduce the time complexity by converting arrays to hash maps, then finding the difference by subtracting sum from the first list element and checking if that difference is a “key” of the second hash map. I am still not exactly sure what this has anything to do with the front-end developer position I was applying for, where I would primarily be working with React, Node.js, JavaScript and CSS. If you are going to test my knowledge, at least ask relevant questions for the role. The third round was a 1-on-1 and it also had a whiteboard problem, however, this time the task was to create an accordion component. I was able to come up with a rough solution on a whiteboard, although tasks like these should be done using a laptop and a projector, if possible. The last round was a 1-on-1 with a senior front-end engineer and mostly involved me asking general questions about the role and the company. Again, this was another mostly positive interview experience with Startup E. I felt like it went better than my earlier interview with another team.
April 20, 2016 — No offer, no reason given, they decided to move forward with another candidate. When I asked the Startup E’s recruiter for a feedback — no reply. Feedback is too much to ask for these days, apparently. And this is not even half as bad as experience of some people who submit their take-home projects that they’ve worked on for days, or even weeks, that never got as much as a reply from a recruiter. And then you wonder why people get an interview fatigue.
I wish there was a word to describe how I feel right now…but nothing comes to mind. I have an urge to write an angry reply to a dozen of emails that I get from recruiters on a weekly basis, but instead — I just delete those emails nowadays, without feeling any remorse like I used to in the past.
It is really unfortunate it has to come to this, because I love coding, it is one of my greatest passions. If a 960+ days GitHub commit streak doesn’t prove it, then I don’t know what will. Don’t misunderstand, I do not consider myself to be an excellent programmer, maybe an average at best (who can’t even pass a single tech interview), and a GitHub commit streak has absolutely nothing to do with one’s competence, skill or ability to code. As I have said — I enjoy writing code and that’s the reason why I do it. We, engineers, are so fortunate because we get paid to do work that most of the time doesn’t feel like work at all, in contrast to the work my parents do every day. As for me, my job at Yahoo was my first and will likely be my last one. Enough is enough. I’ve hit my limit with this broken hiring bullshit in tech. No more.
As much as I would like, I don’t believe this story will change anything at all — things will just continue business as usual tomorrow. I am not the first, and I will not be the last one to write about “hiring is broken” stories. Give it a few weeks, and you will see a similar article on the front page of Hacker News. You have to adapt and deal with these frustrating tech interviews or you go do something else instead. I choose the latter, even if only out of the principle.
So, to end this story on a positive note, I will continue working on my GitHub side-projects — both maintaining existing ones and releasing new projects. In fact, I am working on a really awesome and exciting web tool that I plan to announce in late May! Additionally, I have some big plans for Satellizer — 1.0 release, React port and Angular 2.0 support. As for my source of income — I will figure something out. There is always consulting and freelancing, or switch careers while I am still in my 20’s. Or perhaps I will follow in TJ Holowaychuk’s footsteps and start my own company. Sky is the limit, if you’ve got time, money and motivation!
Thanks for reading!
Cheers,
Sahat
RELATED POSTS
UPDATE 3
There is so much negativity surrounding this story — I am getting attacked left and right, not by hiring managers and recruiters, but by my fellow programmers. Many comments are just personal insults directed at me, rather than the article or the hiring process in tech. But for all the hate and criticism, there seems to be just as many supporters who wholeheartedly agree with me on the issue.
If you haven’t noticed already, there is a massive divide in the community. Regardless of your personal opinion about me, there is a problem in the industry, otherwise this article wouldn’t have generated over 600+ comments on Reddit, 600+ comments on Hacker News and 100,000 views on Medium in the first 24 hours.
Instead of launching personal attacks at me or at each other, let’s work together and try to make this industry a better place to work at, starting with hiring.
UPDATE 2
Company names have been anonymized (with two exceptions). Why? I feel that I’ve made my point clear and said what I wanted to say. A few companies mentioned in this article have already reached out to me as a result of this post. But wait, isn’t it a little too late? Yes and no. Again, my point has been made and the story has been heard. I may have burned a lot of bridges by putting these companies on the spot and I have received a lot of judgement and criticism by putting myself on the spot, however, their further involvement with the story has no real benefit to me or to them.
UPDATE 1
I have never seen a Hacker News discussion so divided, thank you for all your responses, however, I feel that I should clear a few things up here.
I was told that I am already antagonistic, annoyed, and planning for failure before going into an interview. Some people have expressed an issue with my attitude, or at least the way it comes off in this post. Someone assumed I am the type of person to “rage quit” and have tantrums. If you read the HN discussion (link above), you will find plenty of people having similar feelings and aversion to tech interviews. I just happened to openly blog about it with full transparency. Also, keep in mind, this is a recollection of my interview experiences, some as far as 3 months ago, which may or may not accurately depict my mood, attitude and outlook — before, during and after the interview.
Some people have also expressed an issue with my rant about algorithms. For the record, I do have a degree in Computer Science, and I have read a fair amount of Introduction to Algorithms, 3rd Edition during my college years. Do I remember how to implement those algorithms? No. Do I need to? (on a daily basis) No. When I am building something that requires the use of those algorithms, I will go look it up. My point is — asking to implement something like a BFS on a whiteboard (however simple and trivial it may be) has absolutely no relevance for the majority of open software engineering positions (especially front-end), neither does it test problem-solving skills if a candidate has memorized a bunch of algorithms one day before an interview.
Lastly, I may have made it look like recruiters are these terrible, evil people, but my frustration was not directed at them, but rather at the interview process.
Thanks again for all your comments, feedback and support!