Lately, a lot of my friends have been preparing for (tech) interviews, and being a good friend that I am (:P) I have been helping them with my "tips and tricks". however, that's when I realized that how scattered my own thoughts were, rightfully so, Since every interview is a different experience with its own learnings and no two interviews can have the same takeaways.
So, with the help of this small article I'm going to try and curate all my learnings and experiences so far whilst also sharing the tips that I usually follow while preparing for an interview that I really look forward towards.
pls note:
- This article is more about how to tackle an interview and how to prepare for it along with how to handle the outcome. My thoughts are with technical interviews in mind, but probably could be extended to other type of interviews like behavioral and HR round.
- Applying for a job, preparing resume, and Recruiter/HR calls are out of scope of this article. If I happen to write about that some day I'll link it here.
Since this is my first ever article on this website, I'll start by sharing little about myself, feel free to skip ahead if you already know about me, or simply wanna skip to the good part :P (if I happen to create a dedicated article or a portfolio website explaining just about myself, I'll just link it here in the future in order to shorten this article)
A little about me
I have always been interested in computers since the age of 7 and thank to some really helpful friends I was able to get into coding at the age of around 15.
I started off as an iOS Developer, following different courses, building projects in hopes to learn various libraries and frameworks (for example RealmDB, Vapor etc.)
I won Apple WWDC19 Scholarship when I was in 12th grade just before starting University, which opened me into forming great connections in the Apple development ecosystem who are great friends of mine to this date and have helped me countless times when I got stuck in life, career-related and otherwise.
Eventually I learned Backend development using Nodejs and Typescript and also some low-level development using Rust due to my interests and hobbies.
I worked as a freelance developer while I was in University and ended up working with great people behind QuestBook, Texts.com, Chatdaddy.tech, Fold.money and more as an iOS, WatchOS and Backend Developer.
I made a lot of friends along the way and have learnt a lot, made mistakes as well and lost a lot of great opportunities. With the help of this article I'd hope that some of my learnings might help someone out there :)
Before Interview
Before I go over the actual interview, there are a few things that one should keep in their mind while preparing for an interview.
Mentally preparing for the interview
Interviews are essentially there just to check if the candidate and the company are compatible with each other, there can be a person who's well-verse with many things along with a great career history. Sometimes the requirements of either party simply don't align and that's alright.
Many times companies when posting job opening don't really explain in-detail who they're looking for. There are many functional parts to a product or an app. And there are developers who're better at one thing than the other. For example,
There might be a dev who's more comfortable and really good at UI along with Animations and knows every ins and outs of the UI, but might struggle with the Architecture, system design or the Dev-tooling part.
Similarly, someone might be top notch at Architecting an app but not so good at UI.
Now, depending up on the company's requirements at that specific point, a company might be looking for a great UI guy and might reject a guy who had absolutely top notch skills in Architecture.
And thats alright, an interview isn't the end of the world, "there are many fishes in the pond", even if one doesn't get into their dream company one might get bigger and better opportunities in a different organization or even the same org later down the line. Being optimistic is the key.
Preparing for the interview
I strongly believe that an interview in its essence is just a psychological game and the candidate should be the one driving it. I have seen many friends treat interviews as a school/college viva or a QnA session and just answer questions in a few lines and then keep quiet.
This is VERY wrong. You're not opening up to the interviewer, the interviewer most probably doesn't know you and they probably only went over your resume in less than a minute before the interview.
The way I like to prepare for an interview is by going over the company's tech stack and see what skills and tech they're already using and what all things could be beneficial to them. I like to go into a rabbit-hole of how things work and various ways something can be done (like different methods of scaling Nodejs backend server)
Then I like to go over the things I have already done in the past and create a small doc in notion and write down my previous accomplishments in bullet-points, because it is very hard to explain yourself in an interview within 20 mins or so especially because years of experience means that you forget some key points.
Interview
I get it, an interview means that the interviewee is probably full of anxiety and nervousness and many people don't accept it but its true and it honestly happens with everyone, at least at some point.
The way I like to overcome nervousness is by gaslighting myself into thinking that the interview I am giving isn't even an interview, and that I have already been hired and I'm just having a general conversation with the my manager because he's interested in the new joinee. That way i am able to explain things and also about myself with a lot more enthusiasm and naturally. This approach is something I learned from my friend Rudrank Riyam as mentioned in his own article about his leetcode preparation and how he ended up grabbing internship opportunity at Apple. I highly recommend reading his own article here.
Like I said previously, an interviewee should be the one leading an interview and not the other way around. The way I do this is –
Most likely the interviewer will be asking about myself the first thing in the interview, during that introduction I like to slip in a few "buzzword" keywords that I am well acquainted with, because the normal tendency of an interviewer usually is to pick those words and question them out of curiosity and interest. (For example, somewhere in the introduction, slip-in having worked with gRPC, raw queries, AWS etc. And let the interviewer question about these topics later)
And since, I've already gone through the rabbit-hole of things that might be useful to the company, I usually slip those things as well, since I just read about them in detail and even if I don't have hands-on experience with it, I'll be able to answer most of the questions quite easily.
Once the interviewer picks those keywords its just a game of leading the interviewer from one thing to another whilst also explaining what you did and how you did it (preferably also sharing the positive impact it created).
It is generally also a good habit to let the interviewer take the lead sometimes since then you'll be able to understand what the interviewer and in-turn, the company is looking for, and with that you can strategize and take the lead in the direction which would help you secure that interview.
It might be very confusing, but let me try and explain with an example:
Interview Example
I recently interviewed with blkbox.ai. I had researched about them and found out (through their landing page, and through a friend that already worked there) that they're bootstrapped and at the stage where scaling their product would be most beneficial to them.
Ofc, the interviewer would out-front say the things they're looking for but they might frame it in the questions they ask, but since I had the glimpse of what they were looking for, I was able to catch that scalability thing in their questions. And I had gone through the parallelism, concurrency and NodeJS cluster module beforehand for this purpose.
I was able to answer questions related to low-level nodejs and how theres a misconception of NodeJs being single-threaded, which isn't true but in-fact its the event-loop that's single threaded and we CAN achieve parallelism in nodejs since it also provides us low-level function to spawn child processes and such.
After hearing all this, the interviewer gave me a question on how would I fix an API that's taking a lot of time – It's an open ended question, so I gave a diplomatic answer as well – We'd need to figure out what that API is actually doing, if the bottleneck if in the DB then we would have to handle that but if we are doing some kind of IO operation that is also stateless then we could split that task to be handled in the background.
- I also went over the cluster module and how it can be used to split IO dependent tasks provided they don't depend upon each other (stateless)
- Could make use of kubernetes or Lambda function rather than using cluster module etc.
- It's fine if we haven't really used cluster module ourselves (which i had not at that point), knowing how it CAN be done is sufficient. And I knew it can be done because i read the official NodeJS doc.
Confidence is the key in an interview, I have also been in interviews where the interviewer said something which was wrong – I mean they're human as well and they can make mistakes as well. Being able to point out what they said is wrong and standing your ground (whilst being polite) can add brownie points to your credibility.
DSA Rounds
Although I am not a fan of them especially if they ask intense things like DP or such, because I feel in everyday development its hardly ever used. Yes, you might argue that there ARE times they are helpful, but I'd rather google an algorithm and solve the problem at hand rather than cram the algorithm and its solution 🤷♂️ But, yes if you're doing backend or especially anything low-level algorithms are a must and you should know every bit of performance overhead something has.
As for DSA rounds, the idea is the same – Lead the interview, but the only catch is that in DSA rounds the interviewer is more interested towards the solution you're coming up with rather than your past experiences.
In such a case the way you should lead the interview is by being over-verbal with your thoughts, DISCUSS the question, tell the interviewer whatever you're thinking, if you think or if you know that your approach is wrong, let it be. Talk with the interviewer anyway. they would be more than happy with assisting you.
Many times in a DSA round, the interviewer is genuinely love solving DSA questions and they might give you subtle hints here and there but only if you are approachable – its normal human nature, will you be able to talk to someone you don't know and hasn't said a single word for the last 10 mins?
Google interview Example
I interviewed at Google once for iOS, 1st round was a preliminary round with an engineer from Google Poland, and that guy was VERY friendly and genuinely loved solving DSA questions -- it was evident from the way he spoke enthusiastically especially when explaining certain algorithms and such.
Being a Dev guy I didn't know how to solve a Graph question directly, I had mentioned the same to him that if I was faced with this situation in real life i would have relied on google search for help but I was confident enough to solve it.
I ended up discussing everything I was thinking and the guy was kind enough to lend out a helping hand whenever I made any syntactical mistake or a mistake in the algorithm in general.
We even had a brief discussion period discussing the algorithm which would solve the question before actually started to code.
Although, I didn't make it into Google, the experience was nothing like I had experienced before. And my point with this example is to be over-vocal with your thoughts, the interviewer isn't your enemy they're simply there to help you.
Finally, an interview is essentially just a game of human psychology and luck. People many times underestimate the luck factor but it's there and it affects a lot. But we cannot control luck and can only maximize on things that are under our control. It is a real soft-skill to handle and lead an interview, and like all skills anyone can hone their interviewing skills and I really encourage anyone to take part in mock interviews with friends or with colleagues or if you have the opportunity, ask your manager to interview new candidates.
Being able to shadow an interview (where you sit there and listen to the whole interview process done by someone else from your org) is also a great way to understand the interviewer's thought process and it will help you prepare better as an interviewer and an interviewee.
After Interview (handling rejection)
After all the blood, sweat, and tears comes the final outcome :P it might go the way you would have expected and the result might be VERY unexpected in multiple ways.
You might have cracked the interview when you thou you did terribly, or you might not have cracked the interview when you thought you did great.
Despite of your expectations, a loss is a loss and it comes with a huge disappointment and sadness, and that's alright. Ranting to friends or family usually helps a tonne.
Always remember, a rejection is not a failure, at the end of the day you didn't lose anything, rather you took home a great interview experience that helped you hone your skills. Maybe you even identified parts where you could improve your interview skills, or learned about new things which you are really excited to learn about and talk about in future interviews.
Personally I feel that a "why do i care, their loss" and "move on" attitude helps a lot, it's totally fine to let yourself believe that its the company's loss that they didn't identify the potential within you and that you'll prove to them what they lost by getting a far better opportunity. But one should do all that without actually keeping grudges against a company.
Finally, always believe in yourself, never lose hope and build your confidence and self-esteem while also honing your interview skills.
Bonus points
- Talk about cool projects you did in the past in the interview, talk about the problems you faced and how you overcame them and things you learned new.
- Make bullet points of everything useful since you might forget some things in an actual interview
- Portray your willingness to learn by asking questions to the interviewer -- how are certain things implemented at their org, if you just talked about websockets for example, ask them if they are using it and if they are, ask them questions like why not something else. Like why not go ahead with SSE (server-side-events) if its applicable in their use-case.
- If gotten the chance then go over the recent dev news, maybe talk about new additions to React or similar. Portray that you love to stay up to date with the industry and and dynamic enough to incorporate those new changes to improve code quality and dev experience
- It is good to be expert in a nice and have strong knowledge about everything in general, always keep learning you never know what might play in your favor in an interview.
- If you talk about a certain solution to a a problem that the interview gave you, support your solution by giving references of other companies implementing the same thing in a similar fashion. For this, subscribe to newsletters and read technical docs of various companies. Discord has really good technical articles explaining how they store million messages in a second for example.
- Follow great people on social media like Twitter/X which often share valuable information.
- While answering a question throw in a few things you know related to it. For example if asked about RxSwift, talk about how you have used Apple's first party reactive frameworks like Combine, Async-await. But beware mentioning these things mostly likely will lead the interview in that direction (interviewer asking about your experience in using Combine etc.)
- Project based learnings come a long way, keep building and posting about them in social media, create a network that will not only help you make valuable friends but also create strong credibility in the field.
- If you're not good at DSA, it is alright to share that with the HR/Recruiter by giving strong evidence that you are good at problem solving as seen in your previous organizations but would like a Dev or role heavy interview instead. Recruiters would be more than happy to try that for you.
- Lastly, practice makes perfect, practice DSA, practice dev, practice interviews sooner or later you'd lose your fear of interviews and would be able to breeze through interviews.
