You’re More Than Your Hard Skills: How Do You Showcase This in an Interview?
Demonstrating Your Non-technical Skills in Technical Interviews
Out of the 20-or-so interviews I attended in the recent internship interview season, I’ve had my fair share of mess-ups from having to email the hiring manager for a lost Zoom link after changing my mobile phone, to long and illogical rambles, to literally forgetting about and missing interviews. Here are the stories of my most memorable interviews and the lessons I took away from the whole process.
Defining your interpretation of the question
“How would you design a lift (elevator) for a 1000-story shopping mall”? This was a really unique and fun question that I was asked in an interview for a UX engineering role. I started my answer by evaluating how users would input their desired floor and the number of button presses they would need in the process. In doing so, I was making some assumptions such as the simple fact that there would be physical buttons for users to press.
After rambling on for some time, I eventually realised that there were much larger problems that should have been addressed before the marginal UX improvements in reducing button presses from 5 to 4. My understanding of the case problem is that a 1000-story shopping mall would pose difficult resource allocation problems, say in situations where many people want to go to the same floor, or when people already in the lifts want to change their destination floor. Hence, I landed on a final recommendation to have an app for users to join a digital queue with an algorithm that could handle the matching of available lifts to users to minimise lift travelling and waiting time.
It’s not that my initial answer was wrong, but that interviewers usually have a general direction of the answers they are looking for. I did need some prompting from the interviewer to go in this direction, and it could have been a much clearer answer had I been more structured.
In hindsight, here’s the thought process I wish I had gone through during the interview:
- What are the unique challenges which a 1000-story shopping mall would face?
- From the challenges listed, which one of the challenges will I focus on?
- How would I approach this challenge with a design that is usable, viable and feasible?
Predicting follow-up questions
I had my first ever technical interview where I had to share my screen on Google Docs for a software engineer role. The problem involved determining if a given string of brackets is valid, with the conditions that the brackets had to be of the same type and had to be balanced. I started off by talking through my thought process on how I decided to use a stack data structure and outlined how I would iterate through the string. While I did manage to solve the algorithm, there was a rather awkward silence where both myself and the interviewer were unsure if I was done.
After some time, the interviewer followed up by asking if I was done and got me to explain my code and address certain edge cases. While it would not have made a difference as to how well I solved the algorithm, being more proactive in this case to have further explained my thinking would have given the interviewer more confidence that I truly understood the approach and was not just spouting out an algorithm from memory.
Here are the questions which I believe anyone in live algorithm interviews should proactively offer the answers to without being prompted:
- What are the assumptions behind your input?
- What are the edge cases? (Those you have tackled and those you have assumed to ignore)
- How does the overall algorithm work? (Explain this in simple terms once you are 90% confident with your algorithm)
- What are some alternative approaches you could have taken?
- Why did you choose this approach?
- What is the time complexity?
- What is the space complexity?
Prepare genuine questions beforehand
The weirdest interview I had was one which was meant to be more ‘casual’, but the ‘interviewer’ remained rather quiet throughout and I had to scramble to ask the questions to carry on the conversation. A successful interview in this case would have been on the grounds of being able to carry a good conversation, to be interesting, to be relatable. I didn’t do too well in this particular interview as I had been caught off guard.
My most memorable interview, however, was with the CEO of a food-science AI startup who shared that he did coffee research and their office had a $4000 coffee grinder in their office (The EK43!). As a huge coffee nerd, it was a thoroughly enjoyable conversation and we even shared our list of favourite coffee places in Singapore and New York. I think what made the difference was that I was genuinely curious about my interviewer’s background and I was fortunate to have some common interests which made it far easier to connect and relate to each other.
Other ways which one could do this would be through showcasing a deeper understanding of the role by knowing the ‘humour’ or problems the interviewers face in their daily lives. (E.g. What does a scrum master do all day? How do you explain what a product manager does to your mom? Everyone does everything in startups etc…). Put simply, it’s finding ways to appreciate and relate to what the interviewers do or which the role entails.
To sum it up, being structured, proactive and relatable sets you up for success in interviews, technical or not. We often criticise hiring managers for not being ‘personable’ in interviews and lament about being treated as ‘just another candidate’. I hope you can see, however, that interviews are fundamentally a two-sided process that is nothing more than the simple practice of forming human connections.
