Preparing for tech interviews
Prespectives & advice from the community
u/knucklehead_whizkid on a post titled What are untold tricks / folk knowledge about campus placements (apart from "practice Leetcode" and "read Cracking the Coding Interview") shared the following advice:
Lot of people here have given some great technical advice, let me offer a slightly non-technical component in addition.
Disclaimer: these are based on my personal interview experiences (not a whole lot, I've only interviewed 3-4 times and have been working with the same company for ~7yrs now) and based on the candidates I've selected from campus interview myself.
Confidence and intellectual honesty are key. Sure, you need to have a good technical knowledge base and coding skills, but communication is key and people who say it isn't haven't interviewed other people perhaps. You might have all the answers but if you aren't going to be able to convey your thoughts easily, having those answers isn't very useful.
And by intellectual honesty, I mean that it's okay to bluff a bit on your resume n all but make sure you let your interviewer know if something isn't your cup of tea, don't go bootlicking and say you know xyz when you've just done a hello-world level thing in it. Eg: If you think that you don't know the exact solution for a problem, but an unoptimized one, start with it; and mention that hey this isn't the most optimum thingy but I'll start with this to build something that works and then optimize later on.
I've seen a lot of candidates who are really smart but if they aren't going to communicate confidently (what they know and don't know) then they're hard to integrate in a team. On the other hand, a lot of candidates because they were more open to have engaging conversations, discuss different approaches and tangents to a problem have gotten selected despite not having exposure to some technology just because they were able to demonstrate their ability to learn.
PS: This is essentially a verbose version of the "have an open conversation" tip below.
u/vaibhav-kaushal shared following advice on how open source development can help in cracking interviews:
TL;DR: Open Source development kick started my career despite being a college dropout and I think it is a great way to impress your interviewer.
Hi everyone. I have been watching the posts at r/developersindia since at least two years. I do comment and partake in discussions as well using another ID. Before I proceed, let me first introduce myself.
I am Vaibhav, a middle-aged (35+ yrs old) man working in the IT industry since 10+ years (but doing software development since more than 14 years now). I have been a FullStack (Web+Backend) + DevOps guy since the beginning but am mostly backend-heavy these days. In the past I have written for a few Tech Magazines which includes Digit, CHIP and Linux for You. I started the journey with the security domain so I do have some basic knowledge around that too. I have been one of the core developers of a PHP framework in the past (named QCubed) which has been used at NASA, Stanford School of Medicine and was the framework in which the world’s largest Chess community site (Chess.com) was originally written.
Now, back to the point. One of the most (if not THE most) frequently asked questions on this sub is about how to get into a job (aka "how to crack the interview"). I have been taking interviews since the start of career (10+ years) and have been on both sides of the table. So I believe I am qualified to offer some insight into the process and offer help on this topic.
Most people think Leetcode is THE DEFINITIVE ANSWER. Sorry to state but that's NOT TRUE. I have worked with a couple of guys who were champions in competitive coding and honestly they were bad with everything else and that's a huge problem. Now Leetcode (or similar sites) are useful in training your mind to think in better ways. They teach you to think in innovative ways and make you proficient in basics of DSA. But honestly, in my career so far I never had to write a merge sort or invert a tree; never.
So what do people look for in candidates? Unless you are trying for MMAANG, where DSA skills is mostly a filtering mechanism, you don't need the god level expertise with DSA. What impresses me (and a lot of other guys taking interviews) is "experience".
So now you must be thinking "but I need a job or at least a meaningful internship to get experience". And that's where most people, at least in my observation on this sub, are wrong.
When we look for candidates, we look for people who can solve problems in innovative ways; people who have the ability to go deep into a subject and find out why a bug exists; someone who already knows how to handle git; a guy who knows that part of the job of writing the software is to read other people's code and understand why something was done in a certain way; someone who understands that documentation is pretty important. I expect him to know the basics of the environment where his code will work (browsers for FE, Kubernetes/Cloud/VM for BE) and so on, what it will interact with (REST APIs, gRPC, GraphQL, Auth mechanisms for FE and DB, Cache, Logging frameworks etc. for BE).
NONE of that needs you to have an internship or job. If someone has put up a profile with some experience with an existing Open Source project or has built something cool that solves a real problem, it catches my eye. Regardless of other factors, the desire of me wanting to talk to him is pretty high.
Now, if you built a Library management system (or something similar) using 10 files in Python, I am sure no one is using that and such software are already there. You have zero visibility into how many use-cases are lacking, what the real-world bugs are in the code and so on. It probably cannot handle enough traffic and is organised poorly. So basically I am looking for "meaningful work" - whether you contributed a small feature or fixed a bug in Kubernetes or made a Logging library which is super easy to integrate and use, you are experienced with the domain in a meaningful way. You
- must have some insight into code organisation
- must be knowing fundamentals of git
- must be knowing how to structure to your code
- must have decent communication skills
- must have read through and understood basic documentation related to the subject
- must be (very important) passionate about solving an existing problem
All of this is "experience" that makes my life easy as a senior/lead developer. It tells me that you, as a junior/colleague, would not need hand holding on basic stuff and that I can count on you to understand the dozens of dependencies on existing codebase and its functionality. Of course it does not mean that you should skip on DSA or that DSA is useless! DSA is still very much required, although being a DSA god is not required for most things we do in the software world!
Related Discussions
- My tips for interview in product companies in current environment..
- Questions to ask in an interview as an interviewee.
- Why I think interviews are often flawed?.