I interviewed them; and they disappointed — 4 mistakes to avoid in a coding technical interview
Being someone with 2–3 years of experience in technical firms as a software engineer, I’ve given a lot of technical interviews and it is for sure unavoidable. However, the tables turned recently when I was given the opportunity to take interviews of potential candidates and most managed to disappoint me pretty well. Below are a few things you can steer clear of when giving your next interview.
1. Not able to explain your past projects or your contribution to them.
This is a huge no-no, this is probably the first thing I’ll ask or anyone will ask and will build the base of your profile on. Confidence speaks volumes here; if you played a vital role in your project but you’re “not able to explain it well” that is also a problem in itself, it says you don’t have proper communication skills and won’t be very efficient when working with a team.
2. Not knowing the basics (specially if you dare enough to put that on your resume)
What is a set? What is BST? And you said you’re good with data structures? What is OOP? “It’s a way of programming” — that’s all you’ve got?
This is pretty self-explanatory and it should not be reiterated, a technical interviewer assumes that you know the basics of programming and things you were taught in college. For instance, if your resume says you’ve completed a B Tech degree it is expected of you to answer OOPs, data structure and algorithm related questions. Even if you never did any practical projects, you should have the theoretical background of coding practices.
3. Not able to structure your thoughts
Honestly, it is not as important as the above two, specially if you are a fresher; I believe thought structure comes with experience, but if you are able to show you have a streamlined thought process it gives a great impression.
Thought process can be judged by your approach to a solution, you might think that providing an optimized solution right away will impress the interviewer (I know I used to) but it’s more impressive to learn that you started from scratch — a brute force approach — and built your way up to the optimized solution giving an impression that we can always keep improvising.
4. And last, not able to solve the given problem —even to some extent.
If you’re appearing for a technical round you should expect one problem question regardless of whether you’ve put algorithms on your resume or not. So if you’re out of touch with problem solving — PREPARE!
Depending on the role you’re applying for, the interviewer might expect you to solve all parts of the question in the most optimized way or simply present you with questions in increasing level of difficulty just to see your level of problem solving. In any case, a basic grasp on pattern based problem solving is a good start.
These were the pointers for a tech round. If you have 2–3 years of experience you might also want to prepare for the system design round, which is a slightly different game — so stay tuned for that.