Sriram Viswanathan

Music, Software, Privacy, Poetry and more...

The Tech interview - a candidate's perspective

Having gone through a recent period of job search and a sequence of interviews, I thought I’d pen down what I think of the different styles of tech interviews and why I think this whole process needs a complete relook.

Personas - Who are the people involved in the process ?

  • Recruiter(s) (can be multiple in some cases)
  • Future Colleagues (More and less experienced)
  • Future Boss (e.g. Engineering Manager/Head Of Engineering)
  • Boss’s boss (e.g. CTO)

Rounds - how many rounds of interviews are we talking here ?

Here’s a typical breakdown -

  • Coding test - take home test (multiple days) or hackerrank/leetcode (3 hours max)
  • Technical Interviews - at least 2 rounds ?
  • Culture interview
  • Interview with future boss
  • Interview with CTO/boss’s boss (VP Engineering?)

These sum up to 6 rounds - I see this as a minimum nowadays, I’ve seen usually go more than this which I find as a complete put-off even before applying.

What are the interviews trying to measure ?

  • Data structures and algorithms
  • Problem Solving
  • System Design
  • Role specific characteristics - e.g. leadership, learning from failure etc..
  • Cultural “alignment” - belief system, values etc..

This whole process needs to be repeated with every single company that you are applying to, yikes!

What are you giving up when interviewing for each company ?

  • Time - a LOT of it
  • Mental capacity/thought

Both these points equate to both a monetary toll as well as a psychological/mental toll.

E.g. I am an introverted person and it takes a huge toll on my mental health to be talking to so many new people and trying to deliver my best over such a long process.

Mis-alignment between interview and realistic job scenario

This is the toughest cookie to swallow for me and cuts across many of the interview rounds/processes. Let me explain and I’ll take my example.

I have been doing software development for around 15 years now and thats a lot of time. I have worked on lot of technologies and in teams of all kinds/sizes.

The position I am usually applying for is the role of a tech-lead, in a technology agnostic way and where I can find an “inclusive” and feedback driven culture.

The disconnect I’ve found in the interviews are many (I have done many of these mistakes myself but always trying to improve) -

Technology specific questions

e.g. do I know what does “x” mean in a particular language ? or similar.

What is this trying to measure ?

That I actually know what “x” means ?

have I “memorised” this answer already ?

have I worked on this language ?

have I “used” this “x” in this language ?

Data structures/algorithms

e.g. hackerrank, specially ones with highly uncommon data structures like graph/tree/heap etc. Most jobs will never ever use these data structures, only in rare cases. Add the question of “what is the complexity of this” and you get a package of questions that is more theoretical than practical.

What is this trying to measure ?

That I have “used” this data structure in a “practical” scenario ?

do I “understand” when this should be used ?

did I just practice hackerrank for past 1 month ?

did I memorise this “Order of nlog(n)” from a table ?

System design

e.g. design a system like WhatsApp. This question reminds me of school projects that we used to do, where there are a limited number of “models” that students are asked to build every year and you know exactly what shop will sell all the requirements in a box, maybe with instructions included.

What is this trying to measure ?

Have I already “built” a similar system and know the pros/cons in the choices ?

Did I just watch a youtube video that explains this answer ?

Did I just read a blog that explains this ?

Increasingly I find that this question needs to be broken down and made more “specific” in what the expectations are - this shows the interviewer has put in equal thought in why they are asking a system design question. Otherwise, it’s a very lazy way out in my opinion.

Cultural “alignment”/interview

The only thing I’d say here is that words and actions are two different things.

Answering culture related questions with just the “right” words is easy but implementing day-to-day is hard, really hard.

An example question is “how do you deal with failure and given one recent example”. This has become such a cliched question that everyone is already “prepared” for this. Another one is “do you believe in inclusivity?". Who would answer “No” in their right minds if I wanted the job ?

What is this trying to measure ?

Have I “prepared” for the interview ?

Do I really believe in these statements I am making ?

Have I actually “practiced” what I am preaching ?

A haze of ill-measured outcomes

As you can see, each question/round leads to what I want to call “a haze of ill-measured outcomes”. This haze needs to be cleared and the outcomes made concrete.

Engineering as a discipline is about “practicing” one’s skills and “applying” them at the level of one’s experience.

Measuring with clarity” needs to be a metric thats measured on the interviewer’s side and it should be a feedback loop that continuously gets better. Strive for clarity, not perfection.

Recruitment ethics

Finally and not the least but probably one of the most important points - ethics.

I find that there’s a level of “mistrust” between both the candidate as well as the companies. No one’s to blame - its a mess thats been around for a long time and needs fixing and it starts with individual actions.

  • Don’t keep anyone in the dark - this goes for both the candidate and the recruiter/company - if being transparent doesn’t get you the job, is it really worth it ? and same for company.

“Over-communication is NOT a bad thing in my opinion, at least in recruitment.”

  • Do not leave the other person hanging on hope - goes for both sides. Communicate - its free!

  • Respect each other’s time - just because I am searching for a job doesn’t mean I have all the time in the world - respect each other’s time in scheduling as well as how and when someone calls.

  • Respect the individuals - be thoughtful in asking questions that might be “personal” in nature or not-professional - not everyone appreciates that.

  • Respect the process - be thoughtful and respectful of each other - the amount of work that both sides are putting in to make it work for everyone and this has to be visible in each communication that you make - email/call/text and also the time you send those. Do not call a person post-work-hours or on weekends unless necessary or ask for permission before doing so. Just one simple step can go a long way in building a rapport.