Tales of Tech Interviews

And how being interviewed helped me become a better interviewer

• My First Interview
• Interviews with BigTechs
• Product Centric Interviews
• Best Interview Ever
• Parting Thoughts

I like to believe that I’m a decent developer. There’s no real proof of that, apart from the bits n pieces occasional compliments from coworkers; and the absence of outright remarks of evident stupidity over the last ~8 years.

I’ve always loved programming, and - at the same time - I’ve always sucked at competitive programming.
Basically, if there was a gun to my head and the only way I could get out of it was by solving a programming puzzle, I’d start making calls to the people I love.

That should serve as a decent precursor for the tales to come, and how I generally fare in tech interviews.

My First Interview

This was for a BigTech company in college. I was the crowd favourite to get through¹.

The interview started. I was completely bamboozled by the question. I knew I basically had to narrow down to a data structure, but for the life of me I couldn’t settle on one!
Needless to say, the 2nd question never came.
After the interview, a friend was kind enough to point out that it was a ‘simple tournament tree’ problem. Tournament what now?
To me, in the interview room, it was equivalent to being asked to figure out the equation for the quantum wave function in 30 minutes.

Over the next 15 days, before my next interview, I inhaled the contents of Cracking The Coding Interview .
I guess it was only because of CTCI that I feel I interviewed reasonably well. That, and the fact that my interviewers asked some offbeat questions and valued first principles.

Interviews with BigTechs

Over the course of my work life, I’ve interviewed with other BigTech companies only twice - and with predictable results.
Here’s how one phone screen went:

Interviewer: Hey, I'm <name-I-can't-recollect>
Me: Hey there, how's it going?
Interviewer: Going good. Here's your question
Given a number 'n', Print brackets in a certain way

It took me about 30seconds to realise that I’m not gonna get this one.
Don’t get me wrong, I am not a pessimist or a giver upper - I just know what I don’t know.
Still, I tried to solve the puzzle - thinking out loud all the time², which was met by radio silence from the other end.
About 10 minutes in, the interviewer also realised that this wasn’t going anywhere - but we were both duty & honor bound to see it through for the next 30 minutes.
Such a waste of valuable human time. I almost wanted to apologise.
Days later it was pointed out to me that this was a ‘simple DP problem’.

A similar episode came up with another BigTech. I was asked a variation of Binary Search
The expectation, of course, was to get the solution quickly and then code it out (on paper)³ while covering all the tricky edge cases.
If you’re following the trend here, that - of course - didn’t happen. I took like 5 minutes⁴ to get those bounds right; but of course, the interviewer gleefully pointed out all those edge cases one by one. I think this time I did end up apologising.

This is not meant to evoke any sympathy towards my inability to interview well. I’ve been blessed to have a rewarding career so far and worked with some of the best people around - all outside of BigTechs.
This is also not about the grapes being sour - it is not a critique about the process that BigTech companies follow

However, it’s notable to point out that I don’t remember even the names of my interviewers, let alone remembering what they did or about their teams.
I did not have a very engaging conversation with them as they got right to the question.

These are the learnings that I try to incorporate as an interviewer. Most people forget that an interview is a conversation first.
At the very least, we can try to make it a good, engaging conversation. I always start my interviews trying to have a decent conversation with interviewees rather than ‘getting down to business’.
A good side effect of this is that it generally helps the candidate relax.
Sure, they may not meet your standards in the end, but it is still worth spending some time engaging them.
At the very least, they’ll have a decent time and you would have done well as an ambassador for your company.
At best, they would remember that and write about you in a blog a few years down the line⁵.

Product Centric Interviews

My interview with booking.com was my first experience of a process which was tailor made to reflect company culture and priorities.
The first phone screen was taken by a software developer and an employee from the customer experience team. It was a refreshing revelation!⁶. The pre-question and post-question conversation was especially enriching since I got to know more about the company and not just the tech team.

Similarly, in one of their on-site rounds, I was asked a question that circled around a hotel owner’s working capital. This had nothing to do with data structures or algorithms and was the first time I actually thought of a real customer problem during an interview.
I don’t think I did well there and I didn’t get the offer. But I still remember most of the conversation and the name of my interviewer.⁷
The biggest takeaway from booking.com interview, as was pointed out by my interviewer, was “Basically we are here to solve a business problem. It’s important to us to evaluate how people approach such problems”. They didn’t pretend to be a hardcore tech company and were sincere and straightforward about what they were looking for. Despite not getting the offer, I loved the experience.

One of the companies I later ended up working for had a similar interview process and I whole heartedly subscribed to it.
If we are not inventing new algorithms day to day or even once in a while then it’s important not to focus on those aspects of programming, and instead focus on what we will end up doing day to day - which is solving a problem related to the company’s business.
Luckily, I see a lot of companies coming around to this idea.
There may be a lot of you reading this who may not align with this - which is fine. But I do suggest at least trying out with a company with a different hiring process - you may be enriched by the experience alone.

Best Interview Ever⁸

My best interview experience, in fact, wasn’t even an interview at all. It was the initial email exchange I had while interviewing for DataStax.
DataStax is all remote, and I loved how their recruiting process was tailor-made for their needs.
The first email had a set of 3 questions

• What do you know about data structure X and Y. When would you prefer X and when would you use Y
• Develop an algorithm to solve a problem (which was evidently applicable to a distributed database)
• Think about various optimisations to the above solution under different constraints

I was blown away by the simplicity yet effectiveness of this first screening round.
It checked my technical skills, the stuff I kept in mind while thinking of real world implementation && the way I presented my thoughts.
Even though I was really impressed by the screening email itself, I was further blown away by the next task.
I was asked to download Cassandra and implement a certain feature in it. If I needed help, I was pointed to the IRC and mailing list. That’s it!⁹
What an incredible way to screen for exactly what you value - right from the get go (and before any 1-on-1 interviews).
We had to cut the process short since I had an offer from another company - I didn’t want to waste my interviewer’s time, even though I would have loved to go ahead with the process.

Parting Thoughts

To me, Hiring is one of the most important processes for an organisation, yet it is often overlooked.
It basically determines who comes in and sits next to you to share the day to day burden of your challenging work.
It is specifically crucial for startups to ensure that the process tests for the skills that are relevant for day-to-day jobs, rather than aping established processes by bigger companies.

Another part that generally gets missed out is iteration & reflection. Once a hiring process is set, it almost never gets changed.
A/B deployments and iteration techniques are a given when it comes to building a product these days, I wonder why it is not applied to internal processes too.

Also, a quick word for younger devs out there:

Try not to make it your life’s mission to get to a specific company.
There is little to no correlation between how great a career you’ll build with the company you work at.
Being in a BigTech won’t guarantee you’re surrounded by geniuses; and being at a startup doesn’t guarantee that you’ll morph into a rockstar or an urban legend.
If you’re really looking to build a solid and fulfilling career, try to focus on yourself and improving your skills.

Lastly, don’t get disheartened if a few interviews go bad. Unfortunately, no matter how much we try, interviews cannot be 100% objective. So a few of them going bad don’t mean much.
If a lot of them are going bad, that’s ok too - look for a company with an interview process that is different (not easier) than the ones you’re trying out for. You may just chance upon a great fit!

Would love to read about your interview tales too! Please feel free to email or get in touch over LinkedIn

Thanks to Ravi, Sourav & Suman for helping me write this and providing feedback.

Footnotes: