2 “Oh Crap I’m Stuck” Software Engineering Interviewing Tips
--
Some advice you might haven’t seen before
Interviewing sucks and I’ve stated that a million times, and will state it a million more. After reading several articles on software engineering/developer interviews, I’ve noticed a lot of the advice revolves around the specifics of whiteboarding/coding such as “think about a hash map if you’re stuck”. However, I wanted to drop some “here try this” tips that might get you through a slump or a confusing problem.
Note: I will say these may or may not work depending on circumstance or who’s interviewing you. However, can’t hurt to try if things aren’t going well.
Ask for a New Problem (or a Simpler Version)
I’m shocked I don’t hear about this advice more often. Sure FAANG interviews might not allow this because “standards and procedures” or whatever corporate jargon get’s thrown out. However, be honest that you’re unable to solve the current problem in front of you. Asking for a new or a simpler version of the problem allows you to show skills like communication, problem-solving and design.
If doing this doesn’t work out, try solving the parts of the problem and display skills I mentioned above. Even if a single function, try to leave some impression with the interviewer that might give you a “maybe” instead of a hard “no”. Remember, tons of things can happen outside of your interview with other candidates, that this could stand out.
Turn Problem into Pair Programming
Sometimes, the interviewers have vested interest in the problem they ask. Since a lot of firms are struggling to find interview problems they’ll ask engineers to create them. Everything an engineer creates they become a little bit attached to. So running into a custom made problem an engineer interviewing may be excited to explain details or better yet solve parts of it for you. Just listen carefully and make note of how they believe the problem should be solved.
I’ve gotten this to work once where someone pretty much word by word told me how to write the code and I just translated into keystrokes. Now, don’t just blankly ask for the solution, but try to get some feedback on code. Ask questions like “what if I tried this, what do you think?” instead of “how do I do this?”. Any question that get’s interviewer participation will help a lot and show collaboration skills.
Anyways these are my two tidbits of info, thanks for the read.
