0

Dealing with Mistakes, Pivots, and Panic Moments on interviews?

Profile picture
Ex-Software Engineer at Googlea year ago

What would you recommend if you run into a problem where you do lay out a high-level implementation and approach, but once you're in the code writing phase, you either come up with new edge cases or possibilities and then end up second-guessing yourself and going down a rabbit hole? The same question can also be extended to mistakes. Given how competitive the market still is for software engineers, it feels like the margin for error is lower than ever. Before, you could be more collaborative with the interviewer, but nowadays, it feels more of a lone-wolf activity, and sometimes even adversarial based on the general pressure to find that unicorn engineer.

This was a question I wanted to ask Edbert, but I had an obligation that took me away from his talk.

136
3

Discussion

(3 comments)
  • 1
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    a year ago

    There's a lot to go through here, but I want to address the following point first:

    Before, you could be more collaborative with the interviewer, but nowadays, it feels more of a lone-wolf activity, and sometimes even adversarial based on the general pressure to find that unicorn engineer.

    I actually think it's the opposite: You should be more collaborative with the interviewer. However, I think where a lot of candidates get confused is that they equate "collaboration" with "fishing". I cover this here: How To Handle Hints In A Software Engineer Interview Without Failing

    I know that the market sucks, but it doesn't make sense to see the interviewer as an adversary for so many reasons:

    1. It will color all your behavior in a bad light, both consciously and subconsciously. People generally don't act nice to their enemies.
    2. You will collaborate with them less.
    3. In the vast majority of scenarios (at least with good companies), the interviewer isn't out to get you. They are staking their time on the line to interview you. As someone who interviewed a ton of engineers at Meta, it was much higher ROI to work on your roadmap work vs. interview someone. So if I am going to interview someone, I am going to do the best I can to bring out the best in them (I want to pass them!).

    I also don't really think there's a "pressure" to find that unicorn engineer; it's just that any solid company will have a unicorn engineer applying to their open roles because the market is so competitive right now with all the layoffs. It sucks, but that's unfortunately how it is. But hey, you have Taro on your side: There's no reason why you can't become that unicorn engineer. šŸ˜Š

  • 1
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    a year ago

    On top of that, here's the other ground I want to cover.

    Verifying High-Level Approach

    • Explain it in high-detail to show that your interviewer that you are thinking things through and not randomly guessing
    • If you have done the above, you can ask something like "Does this make sense to you?"
    • In general, if I saw a candidate be wildly, wildly off, I would gently nudge them in the right direction (i.e. push them to think things through a little harder)

    Pivoting

    • In general, you want to pivot as early as possible. If it's too late, just finish your train of thought
    • So if you're only 1-5 lines in to your initial solution and you realize there's something way better, pivoting makes sense
    • However, if you're >50% done, just finish your existing solution to get something on the board. You probably won't have time to fully flesh out the more optimal solution anyways. I have had many candidates fail from excessive pivoting

    Edge Cases

    • Don't code them into your solution initially - You can always add them later
    • Remember that the foundation of your performance is the core working solution. Edge cases go on top of that. It doesn't make sense to dive into edge cases without finishing the foundation first
    • A lot of the times, I won't even make candidates code out edge case coverage (it's easy to rabbit hole). I just want to know that they're cognizant of them - That's the most important part

    I also recommend this playlist if you haven't gone through it already: [Taro Top 10] Effective Interview Prep

  • 1
    Profile picture
    Tech Leadership Coach ā€¢ Former Head of Engineering
    a year ago

    I would not factor in the state of the market in terms of how you approach an interview. Sure it's not a favorable market for candidates, but a good approach to solving a problem doesn't change.

    The same principle applies for people. The principles around relationship building and having a health interaction doesn't change. Reciprocity will always play a factor, where open-mindedness and making a genuine effort will be rewarded while hostility will likely be met with hostility.

    I think you're overall approach is good where you validate at a high level before diving into details. The improve is not agonizing over small inaccuracies (especially live during the interview), but having a calm, measured response to it. Don't beat yourself up over an edge case, instead be glad you discovered it and make the most out of this new information.

    Journal on your interview after it's done. Go into detail about what you think when well vs. not play-by-play. I find the more detail you put on paper, the more objective you can be about what's actually happening.