The horrifically dystopian world of software engineering interviews

Trials

My phone goes off.

“Hello, this is Jared.”

“Hi there. I’m calling about a phone interview with Giant Search and Advertising Company.”

“Yes! I’ve been looking forward to our call!”

“Yes. Can you write an algorithm to find the Kth highest value in a binary tree?”

I pause. I am completely blanking. I haven’t seen one like this before. The blank Google doc stares back at me with the cursor blinking in slow motion. I cobble something together as a first pass.

“Can you write a test case for this algorithm?”

Sure. I could possibly do that if I wasn’t completely hazing over and my inner ego was not melting under the blazing fury of a dream dying before my very eyes. Is this what all my hard work over the past few month come down to? I had decided that it was time I found a new position around January of 2019. As if the Software Engineering Gods on high had blessed this very thought, a Giant Search and Advertising Comapny recruiter reach out to me on LinkedIn about a phone interview. This was perfect!

This wasn’t the first time this had happened. As a bright eyed young engineer just out of school I had recently begun my first job and was doing quite well. But then my world got turned upside down. I was working on a particularly nasty bug and did what any self respecting software engineer would do before trying to solve it myself: Google it. As soon as I hit Enter with my suitably obtuse query in the search box the screen faded to black and I was dropped into a shell.

You are speaking our language... Would you like to take a challenge? 1. Yes 2. No thanks

I nearly spat out my lukewarm Costco coffee. I was about to jump up and scream for my coworkers to come look. But then I became suddenly concerned that I was hallucinating and realized I would be hyper embarrassed if this proved to be true. Fearing that I was about to have an out-of-body experience, I pressed 1.

Given an array nums containing n + 1 integers where each integer is between 1 and n (inclusive), prove that at least one duplicate number must exist. Assume that there is only one duplicate number and find the duplicate one. You have 24 hours!

I had a small heart attack. After I managed to resuscitate myself with another shot of Costco coffee I realized that I could totally do this. I already had a plan in my head about how to solve it. So I did. As soon as I hit submit I was given another problem to solve. This continued 5 more times with each challenge getting progressively harder. After I submitted the final challenge I was greeted by another message:

Congratulations! The code is strong with this one! Would you like the opportunity to interview with Giant Search and Advertising Company?

That was it. My whole professional world shifted. One of the most powerful organizations in the world had reached into the psyche of my 22 year old brain and rewrote a register. None of the previous goals I had in my career mattered. Prior to this experience I was blissfully unaware that a top tier company like this was an option for me. But apparently I had somehow proved worthy enough for consideration.

The phone interview was a lot like the nightmares that I had leading up to it. I was asked to program Conway’s Game of Life in 45 minutes. I actually did pretty well. I wrote the whole program and tested it to prove that it was working. I got the rejection the next day. Internally I was both crushed and confused. What had I done wrong exactly? Hadn’t all of the challenges I did counted for anything? Why was I expected to write such a challenging algorithm in so short a time?

In light of my first experience in competing at that level, I decided that this time around I was going to up my game. My interview was in April of this year. I built myself a 3 month study plan and tore after it. I got up and did three practice problems in the morning, went into work to work the full day, came home for a run and a bite to eat and went back to my office for a quiet working environment to do more practice problems. In a three month period I did a total of 114 practice problems. Arrays, Backtracking, Binary Search, Binary Trees, Breadth First Search, Depth First Search, Dynamic Programming, Graphs, Greedy Algorithms, Hashing, Linked Lists, Probability, Sorting, Stacks, and Tries were some of the topics I studied. How could I not succeed with all of this preparation?

Tribulations

The interview with Giant Search and Advertising Company ended in flames. I couldn’t solve the problem. But that was only the beginning of the madness this year. At first I was very strategic about what companies I applied to. I didn’t just want ‘a’ job, but the ‘right’ job.

Next was a self driving car company. I got a response almost immediately after submitting my application and set up an initial code screen. The interviewer answered in a huff and with a very thick accent asked me to code up a very involved image filtration algorithm. I wrote it and asked for feedback. “This looks very good!”, he said. I got a canned rejection email the day after.

Then came an analytics company that asked me to do a take home challenge. The challenge was a three sentence blurb. I did the best job I could on it and wrote a very involved multithreaded image processing system. I got a polite no from the recruiter and when I pressed for feedback I was told that my implementation was “too inefficient”.

After that was a payment processing company. I had a great call with a recruiter and she raved about how well my resume fit with the job description. The next day I got an email from her saying that they couldn’t find a position for my skillset.

Another instance was with a Giant Social Media Platform Company. “Jared! Thanks for your application! I think you would be a great addition to Giant Social Media Platform Company! I’ve sent your application directly to the hiring manager at your regional office!” Eight minutes after this email I get an automated rejection email saying that my skills did not fit the position.

There were innumerable number of third party recruiters that reached out to me. All of them ended in nothing. Perhaps my favorite was an audio processing company. The recruiter reached out and said that the team was very excited to talk to me after reviewing my resume and she would set up a call with the hiring manager. A week went by and I reached out to see what was going on. The recruiter said that she had gotten in touch with the hiring manager and that he didn’t think my skillset matched up. This made complete sense to me and I went on about my day… However, as a test I submitted my resume to a different job posting of theirs and had a different recruiter reach out to me immediately. I was astounded when they immediately set up a phone screen. I have to admit that I only put on a mediocre show for this one. I got a canned rejection email the next day.

Then I finally got to an on-site interview with Giant Internet Retailer Company. I went through a series of programming questions with a number of people across four different interviews and came up with correct and compiling solutions to all of them. Along the way I was asked a series of convoluted and tough “Tell me about a time when…” questions. This was refreshing as it had been the first time in my job search that I had been asked about my experience and acumen as an engineer at all. Then came the final System Design interview. The interviewer promptly gave me a small system to design. I started talking through my solution and was questioned along the way. Finally, we get to a point where he said “Okay, so say we have a Micro Service architecture… Can you design…?” I promptly told him that I don’t have any experience with Microservices. He looked at me quizzically and asked “You don’t? …” I said, “Thats correct. I tried to clearly spell out my skill set and background in desktop, embedded systems, and mobile development on my resume.” He pauses in the way where someone realizes he or she made a mistake. Great! So this man is telling me that after I had spent 4 months studying for this interview, spent virtually every waking hour outside of work completing practice problems, and rehearsed how to present my background in soft skills questions that he didn’t bother to spend 10 minutes to glance at my resume.

Analysis

I could go on bemoaning the many disappointing experiences I had on this slog of a job search. There were many of them. 23 interviews and I didn’t get a single offer. I have always sought to be completely honest and humble with myself and others about my abilities. I didn’t apply to jobs that called for years of experience I didn’t have or for skills that were not near at hand. Sure, I was intending to move back to the web space from the embedded space but I have had two years of experience as a web engineer on top of my other experience as a mobile applications developer and a machine learning algorithm researcher. I fully acknowledge that I have an innumerable number of ways to grow and a lot of on-the-job learning to do. But on the other hand I am very confident I have to skills to get up and running with a new job very quickly. Software Engineering is, in my view, a distilled art form defined by learning and new experience. No Software Engineer seeks to become only somewhat proficient and stay there for the rest of his or her career. At least I hope not: those who do so will very quickly get left behind in the dust. So what is really going on here? After going through this dystopian process for so long I thought I would break down and analyze my observations and then reevaluate to get a clearer picture.

1. We are being consumed by our own mythology - Virtually every popular conception of a software engineer, especially in today’s tech-crazed world, loves the idea of a lone maverick coder who can crack any algorithm on demand with ease. The archetypal software engineer is socially disengaged, anti-structure, and highly idealistic. He or she is fiercely independent and doesn’t need to communicate with anyone in order to get the job done. It follows that because we unconsciously believe in this archetype, I as an engineer must pass a screen that tests for these traits to even warrant speaking to someone who knows anything about the position. But, to the best of our collective knowledge, these traits actually negatively indicate a high-performing candidate. Software companies are made up of collections of one or more software teams. Software teams are collections of individuals.

   • In order to succeed in a group with a common goal individuals must:
   • Communicate with one another - If one member of the team does not know what the goal is it will drag the entire team down.
   • Communicate with non-software engineers - No matter how many software engineers dislike the notion, it is true that it takes more than just software engineers to run a software company.
   • Take direction - More often than not the direction for a product comes from outside the software team. This is sort of the point of working for an organization after all: you are bringing a vision to life that is not yours.
   • Learn from one another - There are always imbalances about who knows what on a team. This is true for both product-knowledge and technical skills. There is a weighted balance in the collective technical skill set for the collective team. This is why we have the hierarchy of experience and distribution of responsibilities. This balance is never, and should never be, static. Someone should always be learning and there is always someone to teach.

   In conclusion to this point, it seems that the popular conception of what is to be a software engineer is driving the structure of the hiring process more that the traits that actually make software engineers successful on the job.

2. We all know algorithm challenges are a contrived game - This point is a little tough to elucidate as there are a number of facets to it.

   • How valuable are algorithms anyway? - There are many points of view to this question. However much I disagree with them, there are parties out there who believe that you can be a perfectly good software engineer without knowing a darned thing about how algorithms work, or even a digital computer for that matter. My counterpoint is that there is a difference between an aircraft mechanic and an aerospace engineer. Which one is more valuable and which one would you rather be? I’ll leave that thought process up to you. A better question to ask might be an inquiry into how relevant algorithms are.
   • How relevant are algorithms anyway? - As much as I believe that knowledge of algorithms and how a computer works is important to be a successful and valuable software engineer, I also know, and everyone else knows, that this knowledge is rarely used on the job. The “Not Invented Here” mindset is pervasive and imposed in teams. For many and most applications this is good policy. If there is a well tested and sure fire library that is able to fill a need it is safer and more appropriate to incorporate it than reinventing the wheel. Round wheels are good wheels so to speak. So, if one were to consider algorithm challenges in relation to this question, it makes one wonder why the heck we even ask these questions anyway. If so many people in the industry think they are not valuable in a Software Engineer’s daily tasks then why do we use them to evaluate Software Engineers?
   • The dark side of algorithm challenges - As to many philosophical questions in life, there is a dark side to these pernicious algorithm challenges. The fact of the matter is that there is a huge quantity of people that are trying to throw themselves into the tech industry. Within a day of a job posting going up on LinkedIn it indicates that there have more than a hundred applicants. Virtually no company has the resources to interview them all. The fact is that these algorithm challenges are put up as a mechanism to ward off the hoard of applicants who are not suited to the job or don’t have basic programming skills. The problem is that everyone seems to have a different notion about what the word ‘basic’ means in this context.
   • We don’t know how difficult they should be - In my time interviewing over the past 7 months I ran across a wide variety of difficulties in the algorithm challenges that were posed to me. On the easier side I was asked to write a function to reverse a String. On the harder side I was asked to imitate a social network and to write an image filtration algorithm. I had one company ask me to do two separate coding interviews. In the first of these I was asked to write an easy sorting algorithm which I nailed. The second was to write a recursive permutation generator using dynamic programming which is no easy task. I got totally stumped in the moment by that one. At the end of the interview I asked the interviewer “This problem seems a little steep for a phone interview. Do you often write recursive algorithms at Payment Processing Company?” He replied “No, we don’t use recursion.” “How about permutations? When have you used those?” He answered “Our algorithms have no need for permutations. Most of the engineers here work on user interfaces and infrastructure.” This made total sense to me. These two instances were for similar level-of-skill roles in different companies. So why did one company pick one difficulty over the other?
   • The measurement is little better than Russian Roulette - Let’s say you are a candidate. You’ve spent the last couple of months studying every topic you can think of that might be relevant to programming interviews. Let us then say that you apply for company A. A asks you to write a binary tree search algorithm. Great! You just got done studying binary trees last week! You pass with flying colors. Now let’s say that you apply for company B. B asks you to write an implementation of a trie tree. NOOO! You forgot to study tries! Because you didn’t study that topic you fail the interview. Now reverse the order and say that company B asks you the binary tree algorithm and A asks you the trie tree algorithm: It is clear that getting hired at some company can be purely an artifact of which problem you are asked.
   • Time limits are detrimental and discriminatory - Generally in a phone screen you are given 45 minutes to solve the coding challenge. This is plenty of time for a simple problem. But when you are asked to write a complex algorithm it is patently ridiculous. When I was asked to write Conway’s Game of Life it took me 50 minutes to get a working, running piece of code and I had next to no time to test it. When I was asked to write an image filtration algorithm I spent the first 15 minutes just to understand the question. I ran out of time. If such a complex algorithm were to be written in the real world, it would likely take a week of implementation and a month or more of real life testing. At minimum. So why are we asking engineers to do it in 45 minutes?
   • There is a cottage industry springing up around passing interviews - All of this algorithm challenge hubub started with popular companies like Google. There were several engineers who worked at these popular tech companies that saw an opportunity to make a few bucks be offering prep material. There were two influential books written on the subject: Cracking the Coding Interview and Elements of Programming Interviews. Both of these books offer guided interview preparation material. The problem is that the industry got a hold of these books and tailored their interviews to the book’s material. However, as soon as people started passing the basic interview questions set out in these books, the companies realized that they were now hiring from the new bottom of the barrel. So they wrote new, more challenging algorithm questions to differentiate themselves and hire the ‘more qualified candidates of all the seemingly qualified’ candidates. There are multiple anecdotes about current and former top tier engineers at particular companies who claim that the interview process has gotten so hard that they would never pass the bar if they were to go through the process now. I watched one talk that had a great story. At one particular ‘top’ tech company the process is that when a candidate goes through an interview he or she has a packet compiled about their interview performance. The packet then goes to a committee whose job it is to impartially review the packet to make a hiring decision. At one point a particular committee got so critical that they rejected every packet for several months. When HR caught wind of this they decided to set up a test. They sent the committee a new round of packets and once again the committee rejected them all. HR then called them all into a meeting and explained that they packets they had just reviewed were in fact the hiring committee member’s own packets from when they interviewed for that company. They had unknowingly rejected themselves! How could anyone pass that bar?
3. Why are we measuring people and not learning about people? - I watched a talk a few weeks ago about someone who had done a large number of interviews at a ‘top’ tier company. In his words the goal of his talk was to “Distill a strategy for ‘extracting a signal’ during an interview.” What?! What happened to people getting to know people? That attitude seems so utterly robotic and frankly quite dystopian. What is the logical progression here? Are we going to scan candidate’s brains to look for similarities between existing high performing candidates? This attitude stinks of an especially horrific blend of egoism and organizational machismo. It sounds to me that now companies are more afraid of hiring bad candidates than they are excited about the opportunity to hire a great candidate. Until companies are more excited about hiring again it’s doubtful it will get any better for candidates. The worst thing about it is that the first message a candidate hears from a recruiter is how great of a candidate you seem but once you hit the interview all you find is suspicion that you are some sort of fraud. It is my view that suspicion should be replaced with guarded optimism.

I am quite sure that I could go on at length. I had about eight more bullet points in my notes to write about. But at this point this article sounds more like a diatribe than a blog article. I hope at the very least I was able to impart some of the difficulty I’ve been through over the past seven months. At the end of things I find myself rather ambivalent. My current employer just laid off my entire office, leaving me without a job and alone to write about how bitter I am about it all. I am not quite sure I want to go through this process again. I have done a lot of thinking and come to some simple conclusions about my experience:

• I know how to write software - I’ve written approximately 85,000 lines of production Java code over 2 years which had a very positive and pronounced impact on the product I was working on. I’ve written some very complex machine learning algorithm implementations in Python along with quite a bit of scripting. I’ve written embedded C and C++ for various low level applications like embedded graphics. I’ve taught myself Flutter and have published several apps. I taught myself Clojure which opened up my brain a lot. I’ve worked on some C#. I know how to build a static web site. I have a Computer Science degree.
• I don’t know why other people won’t let me write software - There is a fundamental mismatch between the public square’s claim that companies are absolutely desperate to hire software engineers and the brutal reality of being a software engineering candidate. These do-or-die high pressure coding challenges seem like more of a hazing mechanism rather than a valuable evaluation tool. Using them is like hiring a police officer by shooting at him before you ask him what he knows about the law.
• I don’t know what its like on the other side of the table - The fact of the matter is that the process I am criticizing may be the only way companies have to sort through the good and the bad candidates. I have never been a part of a hiring team and I am sure there are things going on that I don’t know about.

I have a few thoughts in conclusion:

• Survival of the fittest is real - As much as I would like to reason my way into a cush job at a well known tech company, the reality is that there are a lot of other people out there that are competing for those jobs. Just as with everything else in life there are few resources and there is high demand. Everybody and his brother wants to get paid a lot to write code. It is my suspicion that the reason such aggressive screening barriers are put up is that the proportion of those who have an objectively (whatever that means) lower level of skill is much larger than those who do have those skills. Unfortunately this means that you must compete with this massive amount of people no matter how experienced you are. As any person who has gone through the process of learning to program understands, the learning curve to become even minimally proficient in basic skills is drastically steep. On top of that the body of knowledge that make up the core competencies needed to succeed on the job is vast. Further still it is difficult to gain proficiency in a particular set of relevant and marketable skills, even more to master them. Regardless of what route one takes into becoming a software engineer, it is clear that competition is a fact of life and is quite stiff in this industry.
• Hierarchies are real - I am rather confused with the advertised rankings of a software engineer. There seem to be only two rankings: non-senior and senior. In general job ads ask for 5 years of experience in order to be considered a senior. There seem to be some missing rankings. What do we call someone with 20 years of experience? Are they really the same thing as someone with 5? In my case, what do we call someone with 4 years of experience? I am not a new grad. I know how to write software on my own. I know how version control works and how to exist in an Agile environment. Depending on the situation I need people to set the direction for my work. To add further complexity to the issue, there is the the issue of years of experience in a technology. If a person has 5 years of experience writing Java and moves to a team that uses Python and is made up of only people who have less than two years of experience in Python should this person be considered a junior? This is such a confusing topic that it warrants an entire article of its own and even then I am not sure I can make any sense of it. My point is that I lie somewhere between junior and senior and it seems to be slim pickings for my experience level.

• Complaining about it wont do any good - Sooner or later I’m going to have to get another job. Even if I don’t like the methodology, I am going to have to go through the loop again. But for now I’ve had enough. It seems unlikely that I will get anything to happen by repeating the same process over and over again. I’ll get on the merry go round again eventually but for now I am going to choose the only option that leaves me with my sanity:

  I’m going to exit the loop for now.

from Hacker News https://ift.tt/326b8Bj