The Interview Answer That Cost Me $314K+ Job

Four months back, I was contacted by a gaming software company for a senior developer position. The role was generic: It embraced all aspects of development: Back end, Mobile, and Cloud.

The recruiter summed up the package:

• €150k annual salary (The salary part is €100k. However, in the EU, the employer takes care of medical insurance too. This one promised it for my whole family. Then there are 1-month long holidays, coupled with holiday bonuses)
• €170k stock options spanning 4 years

If I apply those figures over 4 years and estimate the stock to reach even 3x its current value, the total comes to around €1.1M. Note that 3x is most conservative because it touched 1.5x just within the last 4 months of the COVID-struck world economy.

Divided by 4, this comes to about €277K ($314K).

I am not bound by an NDA, but I am not revealing the company name here. This is because I hate stereotyping companies based on interview questions. Besides being harmful, it is nonsensical. No company repeats its interview questions quite often.

The important thing is to understand the pattern by which they go.

With those disclaimers, let us dissect what really ruined one of the most lucrative job opportunities I came across.

The Recruiter Call:

It was a brief, and to-the-point talk.

The recruiter briefed me about the opportunity. Then he asked me about my experience. I summarized it with all the technical terms I worked with that were relevant to the role.

He was happy to know that I perfectly fit the job description of a multi-faceted (T-shaped) developer.

Having known that, he revealed the package details (the ones I described above). His tone betrayed a high degree of positivity and trust. Considering he was a company insider (and not some contracted recruiter), I got very hopeful. I felt like I had already crossed a barrier.

The Call from Hiring Manager:

The hiring manager was a guy with a data science background. I had no background in it, but fortunately, I got a week to touch base on some stuff. The hiring was to be done in the user acquisition team. I read about some UX concepts that were closely tied with user acquisition. I also read about how mobile platforms handled NLP and other AI-related stuff.

The interview began very cordially. The manager was impressed with my 20 years long career in various fields: Desktop, Mobile, and cloud, coupled with some back-end skills.

The most important question came: Why this company? Tell me your motivation.

To nail it with full force (while making up for the lack of my data science background), I said: “I have read a lot about all the concepts surrounding data-driven user acquisition. All I need is a workplace where I can implement those concepts to create the biggest impact possible.”

He was very impressed by my answer. After formal good-bye, I was quickly greeted to the next round: The coding exercise.

The Coding Excercise:

This was the phase I was most scared about. And it didn’t turn out to be easy either.

The challenge included 3 Codility exercises. It was stated that the candidate must not try to attempt them all. Rather, it was advisable to provide complete, bug-free solutions to 2 of them.

#1: Find if in an array there are at least once all the numbers from 1 to K

This problem didn’t need coding. It only needed me to find the bug. However, this being a high stake challenge, I doubted its relative simplicity. Out of 90 minutes, it took me more than 35 minutes to fix the erratic line.

#2: Trim the string up to K characters, without breaking (splitting) a word, and without ending it with whitespace.

For example, if input = “I want to eat an apple” and k=10, the output must be “I want to”. If k=13, the output will be “I want to eat”.

This was bit time-consuming, but I followed it quite smoothly. It left me with very little time for the most complex task.

#3. Given two months as input, find out the maximum number of vacation days one can take during those 2 months. Onward flight runs only on Sundays, and return flight runs only on Saturdays.

For example, if April and May 2021 are the inputs, the output will be (4th April-29 May) = 27 + 29 = 56 days.

I solved it mentally but failed to produce working code before the clock ran out. Regretting it, I sent my solution directly to the recruiter past the clock run out.

I eagerly waited for one long week. I was extremely stressed because I felt I was on the edge. To my advantage, I completed the entire challenge. But it wasn’t well within the time. Also, as I reflected upon it, the challenge wasn’t that complex considering what was at stake, and my experience.

After 10 days, when no response came, I was only half hoping I would make it through.

On day 11, the response came from the recruiter:

“I have exciting news — as may have mentioned, we’d love to progress you to the next stage and set up a video call for you with and !”

I let out a war-winning cry.

The coding exercise had always been the most difficult obstacle in my career. And I had just surmounted it for a big company with huge stock options! The only pending round was the verbal technical interview, where I had way more examples of past successes. I was almost in!

Before the next round, the recruiter called me to express his happiness over my progress. He revealed that the 2 developers will walk through my code solutions in the next round. Referring to them, he also shared the result of my coding exercises. He said that the last solution (vacation problem) didn’t play any part in my selection. I had beaten my competition using only the first two problems! I was elated to know about it.

I felt very happy about the transparency at such an early recruitment stage. I was about to join a company that had such an open culture even applicants! It was surely a rare breed.

I had exactly 1 week to prepare before I would meet Developers A & B, and this interview will seal my future.

The final preparation:

The worst thing about senior developer interviews is that you cannot predict them.

To answer complex questions (algorithm, API, etc), you must get into the flow. To get into the flow, you must code.

However, when you incessantly code, your attention deviates from tackling the bigger picture: The architecture, the design patterns, bigger ideas in programming (functional vs OOP), the software engineering processes, and so on.

I touch base on as many areas as possible in the later section. But it left me with very little time to prepare for job-specific APIs (or so I thought). However, one thing I made sure of was that I went through all the open-source contributions that my future team was working on. I was quite confident about the deepest level of technicality involved in those projects.

At the very last minute, though, I found myself reading about the most mundane software development topics (Agile, TDD, and so on). I had no idea if they would even come, but I didn’t want to leave any stone unturned.

As it turned out, this last-minute preparation played the elephant’s role in my final defeat.

The Interview Day:

When the Zoom call started, I was very nervous. Both developers greeted me. The lead developer took the mantle and asked me a few warm-up questions. I felt a bit relieved, but not as much as I had imagined.

I sensed that he was quite measured in his exchanges. There wasn’t enough warmth in his smiles. At the same time, I didn’t sense any acrimony either. Nevertheless, it was my own stress of the high-stake interview that was occupying me.

Soon after the formal exchanges, he asked me about my experience. I left a smarter reference to my past job where I had worked on a technical challenge their open-source SDK aimed to solve. This brought some smiles to his face for the first time. I was relieved a bit.

Followed by this was the question about software design:

If you were to design software that downloaded some data from the back end, how would you design it for a mobile client?

My answer summarized some classes that were used for HTTP download, followed by the serialization approach using XML/JSON. I also mentioned the segregation of downloading and serialization code. This made him ask:

What is code segregation? Why is it even necessary?

This was the cue I was waiting for, to narrate my knowledge about clean code. I had practiced it very often but reflected upon it only during my recent last week's preparation. I cited Uncle Bob’s principles a couple of times. I described every alphabet in SOLID at length.

This brought a warmer smile to his face. He praised me for my knowledge of OOP and architecture.

To my dismay, the other developer was still impassive. Past introductions, he hadn’t uttered a single word.

It was at this point that things began to fall apart.

The trojan horse question:

A trojan is defined as Innocence hiding lethal intention.

“If one of your team members isn’t sharing enough information with you, what would you do?”

I wasn’t expecting this in a technical round. But it didn’t seem complex at all. From my experience in tackling such questions a decade ago, I considered myself an expert in such questions. Just give the best example of what you have done regarding the situation.

As I thought about it after the interview result, all I had to do to succeed was to provide a carefully framed, realistic answer.

Instead, I went for the real one:

It happened with me when I was working for a Fortune 500 client through my servicing company. The other servicing company had developed the core components. I took the problematic guy into a coffee-table conversation.”

At that point, their faces were expressionless. So I thought of expanding myself by providing rationalization:

You see, when two people aren’t working in unison, one has to start asking: What is it that I can do to change it? That’s what I did. I asked that guy why aren’t you trusting me? Tell me what is my shortcoming and I would be happy to improve.

If he still doesn’t share things with me, I would probably go to my team lead. But I would be very cautious going through the escalation route. You see, trust is very important, and it is better people solve trust problems in amicable ways rather than organizational escalations.

I thought this was quite comprehensive, but their faces didn’t show any feedback. This annoyed me a bit because I could no longer be specific if they refused to assist me with any cues or questions.

The trojan horse opens up:

It was at this point that the mute guy decided to enter the conversation for the first time.

If a bug comes along, what do you do to fix it?

This was quite an open-range question. I had 20 years of experience under my belt. Every company I worked for followed different processes, and those processes had evolved heavily too. How could one answer wrap all of it? It was possible only if I had prepared for it beforehand, but not now.

I chose the company where I worked in the support team, and I did bug-fixing mostly. I went on describing my journey:

Our software was deployed very wide range of clients and platforms. So we had dedicated teams to triage the bugs. Once triaged, bug repro environments will be ready for developers to work on. I was sometimes part of the triage preparation, too. 

Once this is done, I would analyze the problem. Having found the solution, I would create a private branch. Then I would raise review request (Merge requests weren’t the term used in that organization, so I missed to mention the word "merge request".) 

Once approved, I would merge the code into master.

This again didn’t change their facial expressions. As always, I was beyond the point of confusion. So I decided to ask:

If this is not answering your question, feel free to ask me more specifically!

It was the loudest cry from me about being specific. But they refused to pay any heed to it.

You see, no answers are right or wrong! Whatever you say, we gotta hear it out.

I thought to myself:

What kind of conversation is this?

But following my coding exercise round, I decided to clamor on the last strand of hope. I heavily wore my weary smile. It looked like they didn’t want to continue anymore.

To finish up the formality, the mute guy then spent some time going through my code exercises. I kept describing my logic (and some mistakes that I spotted later). No feedback was given.

When we were just 2 minutes short of the timeline, he asked (checking a box-as if it was still necessary, but not sufficient)

When would you consider a product is production ready?

Once I was a delivery lead. At that time I had made the maximum number of releases. But there was no time left to expand on this role. I just summarized the decision point:

100% passing tests, and near 100% code coverage.

As usual, without any feedback, they exchanged niceties and wrapped up the interview.

The result:

Two weeks passed before I got the most dreaded email, which read:

We have decided not to move forward with your application.

As I read about the detailed feedback, my anger piled up:

The thing that left us scratching our heads was around ownership of solutions and proactivity to get things done and drive delivery. This was based on some answers to more open-ended questions which were somewhat theoretical and high level, rather than expressing a structured view based on your own experiences.

How the hell could I know they were asking about taking ownership? Also, all I described were my own experiences. I gave clear examples. What on earth was going on?

Then it hit me: It was the “structured view” (the lack of it) that threw me out of the window. It was the answer that I gave about “tackling the guy who doesn’t provide information”.

There, I blabbered for too long, and they mutely enjoyed my downfall without providing any cues.

The only way I could structure it was to:

• Classify the kind of information that was being obstructed from the problematic guy
• Volunteer to compliment his efforts to share information e.g. create knowledge sharing system
• Escalate if necessary.

But if I had time to bring structure, would I be telling the truth? Didn’t such a structure require knowing the questions in advance, and optimizing your answers?

Your rehearsed behavioral answers mismatch against your actual behavior more often than your rehearsed code against your actual deliverable.

Practice is a great tool for algorithm questions because your reproductions are enough to guarantee your on-the-job performance.

The same isn’t true about character-related questions. Your rehearsed behavioral answers mismatch against your actual behavior more often than your rehearsed code against your actual deliverable.

I replied to the recruiter’s email by citing the point of not getting any cues. I also described all things I had done during my 20 years long career that I could not speak about during the short interview time:

• The variety of deployments (CI, Jenkins), development flows (PRs, MRs, Git, SVN, branching), and project management (Agile, JIRA)
• The variety of cultures and teams I worked with

The recruiter thanked me for the extra insights but revealed his inability to do anything past the point of decision. He encouraged me to apply again after 6 months, basically beckoning me to pass all the 3 grueling rounds again to face the same interviewers, who knew I didn’t hold enough to be a product company guy (despite my having worked with a Fortune 500 product company before. It was all in the CV which they refused to look at).

I stood rejected.

To my ultimate despair, all of this was over:

• The 2-month long process involving 3 rounds, punctuated by 2–3 weeks
• Reading of concepts (+video watching) that I already implemented in live projects
• The dream of getting a $314K+ job

Conclusion:

Senior developer interviews are infamous for the nasty surprises.

Among many of them, though, this one was the most bitter experience I had.

Not only because the position paid well. Not also because they took me till the last point where the waters were the shallowest, and my boat sunk.

It was because my preparations had the highest relevance with the job. I knew their open-source repo components by heart, and they knew that too! Yet, they had serious questions about my proactivity and ownership trait.

Past this, I specifically diverted my attention to look great on the behavioral side. I studied a lot of mock question-answer sessions on Youtube and other sources. I gradually got better.

I also successfully received a job offer from a sizable company that didn’t match this package but was far better compared to my past failed interview endeavors.

One question still nags me:

If behavioral answers can be mocked, whom are they actually hiring?