Placement Preparation for Software Development Roles — Things to Keep in Mind During the Interview
Often my peers and I failed to crack the interviews even after knowing the right solution. Presenting your solution in a coherent manner is probably more important than getting the right solution as many companies (like Google) emphasise the process of getting the solution than the solution itself.
Before I begin: I am not a recruiter. Neither am I a software developer. (What am I really doing giving tips really? XD) What I am doing is sharing the tips I have consolidated in my notes after talking to my seniors, software engineers and reading other Blogs and giving lots and lots of BAD (and obviously, failed) interviews! While I found many blogs on which problems to solve before the interview, I did not find many which gave advice on what to do during the interview. I hope you find this useful!
Intended audience: Aspirants for beginner level Software Engineering roles at MNCs
Most SDE interviews have typical DSA questions (that you would find in places like GeeksForGeeks, LeetCode, etc). Make sure have adequate practice on them. During the interview, Think Out Loud as much as possible!
- Before even thinking of the solution, remove the “fluff”. The problem usually has a context to it, break it down to objective and constraints and input.
- Clarify the inputs. Is the array sorted? Can it have negatives, zeros, duplicates, doubles? How large/small can it be? Is the graph directed? Acyclic? Ask all the relevant and logical clarifications.
- Suggest a brute force approach, and mention the time and space complexity. Mention how and why it is suboptimal.
- Discuss space/ time trade-offs with the interviewer. If you can think of multiple approaches, mention them before writing the code. Can’t think of an approach? In my experience hashing, heaps or binary search usually were the trick ;)
- Write a clean code. Pay attention to your choice of variable names. Use structs where helpful. Create useful functions and organize your code. Create a Util function for a recursive call or a display function for printing the results.
- Now that you’ve written your code, it would be good to check the space and time complexities again. Maybe, what you thought was O(n) is O(1) amortized.
- Check for edge cases. Does the program always terminate? When using stacks: are you popping from an empty stack? If you are using recursion: Have you accounted for all base cases? If you are using pointers: are you accessing invalid memory?
At every step, communicate with the interviewer. The interviewer will give you hints and will also prevent you from derailing too much. It will also ensure he/she knows what you’re thinking! This is very important, and you can practice this with a friend or a senior. They do not even need to know the concepts. But talking to a person and trying to present your solution in a logical manner is an important skill that you can build with practice.
If the interviewer is questioning you on your approach, it is likely that it is not a trick question and you made an error somewhere. Pay close attention to everything the interviewer is telling you. Usually, they are trying to help you. Your temperament during the interview is important. Stay calm, confident and open to feedback.
Revising a few things right before the interview usually helps too. If you use C++, look at the stl declarations: vectors, stacks, sets, maps… Check out memory allocation and deallocation. If you have time, maybe a couple of popular dynamic programming and graphs questions.
Final Tip: If you’re being asked your second or third question in an interview, try to connect it to the previous question you were asked. While it is possible that they could be unrelated, but often a solution to the second question can use the answer to the previous one as a subroutine. For example, if the first question you were asked was to reverse a linked list, and the second could be to fold a linked list. In such a case, the first thing you should consider is — “can the first solution be used as a subroutine, or modified to give this solution?” You’ll only save your time. This is a very common mistake I have made, you could try avoiding it.
In the end, remember giving interviews is tricky, and your performance in an interview does not reflect your capabilities — it only reflects your performance in that one hour, and few (many, really) other variables. There are a lot of things that are beyond your control, so don’t be too hard on yourself if you couldn’t make it. After all, you only need one acceptance!
Good Luck!
As an aside, here’s an article you might wanna check out on relavance of coding tests in SDE interviews.
TL DR: You might not have been tested on the right skills, do not judge your fit for the role on the basis of your performance in the tests!
