Tales of Tech Interviews

And how being interviewed helped me become a better interviewer

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.
I, guess I’ve never been a quick thinker. On the rare occasions I do manage to think quick, I am still incapable of being really fast with implementation.
Basically, if there was a gun to my head and the only way I could get out of it was by implementing something really really fast, I’d start making calls to the people I love. Instead, I am the chap who started off an all night hackathon by writing unit tests1

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 through2.

The interview started. I was aware they generally asked 2 questions. I was completely bamboozled by the first one. 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

Maybe it’s just me, but as an interviewer, I like to start off with some small talk with candidates (focussed on them) to basically ensure that their nerves are at ease and they’re doing OK.
If I can’t come up with any interesting questions about their work or company, at least I ask if they’re well fed and in top spirits for the interview.
Like I said, maybe it’s just me. Or maybe BigTech has a policy against banter.

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 time3, which was met by radio silence from the other end.
All the while, I’m trying to pattern match if there’s any application I know of that may be utilising such behaviour. If I could think of one, then perhaps I could base a solution off of that. I was way off track, of course. It was days later that it was pointed out to me that this was a simple DP problem.
About 10 minutes in, the interviewer also realised that this wasn’t going anywhere - but we were both duty bound to see it through for the next 30 minutes. I continued to talk incoherent nonsense to him. All the while, hoping he’d given up and was making productive use of his time at the other end.
Such a waste of valuable human time. I almost wanted to apologise.

A similar episode came up with another BigTech. I was asked a variation of Binary Search - you know, one of those where we need to tweak the logic applied to ‘low’, ‘mid’, ‘upper’ bounds
The expectation, of course, was to get the solution quickly and then code it out (on paper)4 while covering all the edge cases.
If you’re following the trend here, that - of course - didn’t happen. I took like 5 minutes5 to get those bounds right; and of course, the interviewer gleefully pointed out all the ‘tricky edge cases’ that I missed out.6 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 follow7

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.
That kind of conversation never came up - or even if it did, it was as a quick 30second (mostly obligatory) answer to my 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. Every good conversation has an element of curiosity where at least one party is genuinely interested in knowing about the other.
As an interviewer, I believe, it’s of utmost important that we try to be that.


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 someone from the customer experience team. It was a refreshing revelation!8. 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.9
The biggest takeaway from booking.com interview, as was pointed out by my interviewer, was “See, 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. That was refreshing to see and 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. So instead of asking folks to parrot data structures or algorithms, we had a 2 hour Machine Coding round (bring your laptop - code on your IDE) as well as a product thinking round - because those were the 2 facets of problem solving we’d expect from someone day in and day out.
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

I’m sure readers would excuse the evident hyperbole in the heading there.
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!10
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.
I feel it’s important to constantly evaluate the hiring process and keep tweaking it every once in a while - because bringing in a big bang change half a decade later would be near impossible.11
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.
For example, with most of us working remotely (or even completely switching over ), how about an email based screening process to gauge clarity of written communication?

A bit of unsolicited advice for interviewers12

  • Remember that the person you’re talking to is human and may have interview nerves. Please spend a little extra time ensuring they’re comfortable.
  • Your mindset should be of wanting to hire the person rather than wanting to reject the person.
    Needless to say, you have to be critical in your evaluation. After all, it is your job to determine if the person would be a great asset to the team.
    However, I feel the change in mindset to the former makes all the difference. Instead of seeing triumph in pointing out the next missed edge case of a theoretically complicated problem, you’ll hopefully end up more interested in gauging the thought process of a person.
  • Don’t look for clones of yourself. A hand has 5 fingers, not all of them are the same. Similarly, it takes all kinds of people to build up an org.
    They already have one of you. Don’t spend time trying to find all the qualities that you think you possess in your interviewees. Instead, try to see the strengths they bring to the table.

Finally, 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.
Similarly, being in a BigTech won’t guarantee you’re surrounded by geniuses; and being at a startup doesn’t guarantee that you’re surrounded by hustlers.
If you’re really looking to build a solid and fulfiling 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 , get in touch over LinkedIn or shoot a comment on HackerNews


Footnotes:

  1. Can’t make such stuff up. Needless to say, I was the subject of many jokes throughout the night; Also, please don’t ask if we won :) 

  2. College topper; teacher’s pet; geek etc etc 

  3. That’s the advice you get at all interview websites 

  4. I never understand why we’re made to code on paper 

  5. Oh, the Horror! 

  6. Surprisingly, I did end up getting the offer though. 

  7. If I were to guess, I’d wager that such a process exists partly because it’s a reasonably efficient way to deal with the volume of interviews they have to take; and perhaps partly due to the legacy reasons. For every 1 person who wants to try out something new, they’d have 5 who would resist the change 

  8. I don’t know if they still do that or not, I interviewed with them half a decade ago I think 

  9. Fun Fact: At a later stage in life, I ended up working in payments where working capital - of my company as well as our vendors - was the core problem to solve for :) 

  10. Of course, I was given the fallback to call upon the interviewer if I was stuck. They’re not monsters! 

  11. I’ve seen this happen. Oh Lord, what a mess! 

  12. Each of these are mistakes I’ve made, and was lucky enough to correct by having them being done to me OR having them being pointed out to me