DEV Community


Are You Good At Coding Under Pressure?

calvinpak profile image CP ・3 min read

Are you good at coding under pressure? I am NOT. Going through the interviews again, and the standard process is a real-time paired coding challenge with a shared coding pad. It makes me nervous coding in that kind of setting. I have built large scale projects and dealt with design challenges in complicated projects, but now my entire "worth" depends on some coding exercises that I'm supposed to figure out right away.

I really suck at that, lol. At least in the beginning. Even though I am a nerd who tries to work on Codewar challenges when I'm bored. ;-)

After a couple of weeks of technical challenges, I was 5 minutes away from debugging my two recursive calls today. Once I'm off the call, my mind calms down, and all the codes seem to just magically appear in the right places.

I don't know if this part of the process is a good measure of ability, but it is what it is. If that is what I need to go through, that is what I need to improve on. And here are a few things I've learned:

  • Read carefully: Take your time in reading the questions. There were a couple of times where I left out some conditions which could simplify the solution significantly. Even though the interviewer pointed out as I talked through my thought process, points are usually deducted as a result.

  • Do speak out your thought process: the interviewers are usually not here to trick you, so the good ones will remind you if you were missing something or going down the wrong direction. There is once I spotted a super simple solution to a problem, but the interviewer pointed out that defeats the purpose of the test, lol. Well, it's better to speak out so they can tell you what is the path exactly they wanted you to go down.

  • Always think algorithm: My usual approach is just getting the brute force solution, make it work, then try to optimize. It does demonstrate the ability, but then you will be boxed in the "amateur zone". Take your time to speak out the brute force approach, then spend some time thinking about what kind of data structure and algorithm would make the most sense for this kind of problems. It's easier said than done. I usually got screwed in this process. Pressure drives my brain into the fight-or-flight mode, which is definitely NOT good for figuring out algorithms!

  • High-level design: I found the system design questions kind of hard to manage. I met interviewers who were looking for extremely simple (and usually that implies "elegant") solutions, yet some try to mess with me and make things really complicated. Some of the questions really require some level of experience or research to know the best approach, which we usually can do in the real world, given ample time. There is a pretty good framework you can follow, from writing down the assumptions, to have a component design diagram and a simple sequence diagram. Here is a really useful channel for system design interview tips:

The interview process is very similar to dating, you just have to be patient, try your best, be authentic, and hope eventually you will find a perfect match. Good luck!

Discussion (0)

Editor guide