Technical interviews are one of the most stressful parts of landing a job in tech.

You don't know what questions the interviewer is going to ask. What if you have no idea how to solve the problem in front of you? What if you freeze up and look like you don't know what you're doing?

Many aspiring programmers work themselves up into a frenzy as they try to memorize every coding interview question. You and I both know this approach is unsustainable. I'm here to tell you there's an easier way.

I recently sat down with my friend Michelle, who's a senior software engineer at Stitch Fix (a recently IPO'd company). She shared the kinds of qualities she looks for in developers that she interviews.

Honestly, the qualities might surprise you. I promise they don't include memorizing coding interview questions and solutions.

The rest of this article will unpack the qualities Michelle looks for in developer candidates. I'll translate each of these qualities into key interview behaviors. Then I'll tell you how you can implement them in your own interviews. Let's get started.

Qualities you should have going into the coding interview

When I sat down with Michelle, a part of me imagined I was getting a secret code to cracking the coding interview. I thought I'd hear the ultimate algorithm to solving every problem out there.

While we know a universal algorithm doesn't exist, she did share something even better: how to create a mental a framework for interviewing.

Success is not about memorizing every problem and solution. Rather, it's about learning how to solve problems.

As a developer, there won't be a cookie-cutter LeetCode type of answer. This is where mental frameworks are incredibly helpful. They create just enough problem solving certainty to overcome a seemingly ambiguous problem.

Here are Michelle's key components to building a killer mindset framework for your coding interview.

Be curious

One of Michelle's biggest tips for developer candidates is to be curious. Clarify the problem and ask questions. Share any thoughts you have on the problem you're facing. Interviewers aren't just looking for the right solution. They want to see how you think.

The best way you can show how you think is by asking questions. Let's say an interviewer asks you to check if a string contains any digits. You should clarify the question in your own words, something like:

"So I need to find a way to verify if a set of characters contains any numbers?"

When you say this you're giving interviewers insight into your logic. You're also showing them you're interested in the problem.

And don't be afraid to ask follow-up questions. Using the same example above, here are a few questions you can ask:

"Do the numbers I'm looking for contain decimals?"

"Do I need to sort the characters in any way before checking them?"

Be open to suggestions

One thing that is easy to forget is that interviewers want you to succeed. Most interviewers want to provide real-time feedback and suggestions to candidates. But candidates often take a non-verbal, siloed approach to the coding interview.

One way you can be more open to suggestions is by engaging your interviewer. Verbalize your logic and take them along your problem solving journey.

We'll use the same problem as above. Here are a few ways you can verbalize your logic from the get-go:

"So I'll need to establish a way to separate characters from numbers, right?"

"I'm thinking about iterating through the set of characters from end to end."

"I want a programmatic way to iterate through characters, but stop at numbers."

The more insight you can provide, the more your interviewer will feel inclined to help.

Work collaboratively

This goes hand in hand with the above. The idea that a developer works siloed and alone is a myth. You have version control and project management tools that require collaboration.

You should verbalize your approach, ask great questions, and loop your interviewer in. You'll arrive at the solution much more quickly. But you'll also show your interviewer you can effectively collaborate with other developers.

Here are a few ways you can loop your interviewer in:

"Would a for loop be too simple/complex for this solution?"

"How important is it to establish if there are floats or not?"

"Is there any type of solution you have in mind?"

Be willing to just go for it

Finally, Michelle suggested that developer candidates should just go for it. Meaning, go for the success you want to see.

One of the most common occurrences for candidates is that they freeze up. While this is understandable, no one wins in this situation. You can't show how incredible you are and the interviewer can't help you. Here's what Michelle said to "just go for it":

Even if you have to pseudocode your implementation, that’s better than being too nervous to try. Putting something on the board/coderpad will invite discussion, a chance to share your thoughts, and an opportunity to learn.

Don’t be afraid to fail! It just means you’re one step closer to succeeding. :)

"Just go for it" can mean a lot of things. That said, here are a few examples of what that can look like:

  • Write pseudocode on the whiteboard, paper, or coderpad
  • Note exactly where you are stuck in your logic
  • Verbalize the solution you wish you could come up with

Use the Mindset Framework to Ace Your Coding Interview!

Coding interviews can be scary and there's always the fear that you'll freeze up. Part of this fear stems from not knowing which questions will show up.

The great thing is that you no longer have to memorize coding questions and solutions. Instead, build a mindset framework with the key interview behaviors you read about today.

You want to be curious and open to suggestions. You should work in collaboration with your interviewer. Be willing to go for the success you want to see. Happy interviewing!

If you want to see more of this type of content, subscribe to my newsletter at Course to Hire. I'll help you learn how to code and break into tech. Feel free to add me on LinkedIn as well.

P.S. – if you're interested in connecting with Michelle, ping me on Course to Hire or LinkedIn and I can make the intro.