The World's Worst strcpy, or: How I nailed an interview by getting stumped.

Let's say you got really lucky and landed yourself an interview at a job you really want. You study up for the interview, and prepare in every way you know how. You've studied the algorithms, the syntax, the code, the design patterns, and everything. And you're confident you can ace any little quiz they give you.

Then you come across a question that absolutely stumps you. Something like, maybe:

What is the function of the following block of code?

01 while(*a = *b) ;

What do you do?

In this article I will go through how to demonstrate good engineering habits—which emphasize knowing what you do and don't know, and engaging with information, over recall knowledge.

Stumped

When I encountered this question during a job interview's technical assessment portion, at first I felt the color drain from my face. I was alone in a conference room, given twenty minutes to complete the test. Of course the gentleman who had given me the test said, "If you need anything, I'll be outside," but of course that was just lip service—if I needed anything, that would mean I failed, right?

That judgey look I was afraid to see, when the
interviewer looked at my test.

Wrong. After whittling down the questions to just this one, I knew one of three things could happen: I could wait until my time was up and show them I didn't know what was going on in that loop; I could take a stab at it and probably have the wrong answer, or at best only maybe have it right; or, I could fess up right then and there, and seek to understand the problem.

I opted for the lattermost. It seemed the only logical one.

My interviewer was standing outside, talking to a couple other people, when I opened the door. He didn't look surprised. "Excuse me," I said as diplomatically as possible, "can I talk through this problem with you? I've got the others done but I'm not sure what's going on here."

He was happy to oblige me. We stepped back inside the room, and used the whiteboard nearby to step through what was going on. At first I was self conscious about asking for help, but later I realized how ready and willing he was to share his knowledge with me. After a couple minutes, he had given me enough information that I was able to come to the right answer. Yet I was still embarrassed about not knowing the answer from the get-go.

The rest of the interview went swimmingly, as interviews sometimes do.

It wasn't until I got home that I really had time to reflect on what had happened. And I wasn't sure I had done the right thing until I was given an offer to start working. They actually told me as much, when I expressed my discontentment with how I performed in the technical assessment:

"Nick, you did the right thing. With everyone, but especially new employees, we'd rather have you seek to know than hide in a corner and guess. If you do that, either the job doesn't get done or it risks getting done wrong, which is even worse."

Metacognition

This reminded me of my eighth-grade science teacher, Miss Russo. Through her thick Brooklyn accent she would repeat the word metacognition almost every day. Miss Russo said the one thing she wanted us to take away from her class was metacognition. That's the ability to think about your thinking—to know what you know and what you don't know, and to analyze just what you're doing when you're trying to solve some problem.

Today I roughly equate this to learning any sport. When you're practicing good form or technique, you have to become very aware of your movements—some people are naturals and have decent form without trying very hard, but everybody benefits from actively and consciously training good form. Metacognition is the mental equivalent.

Engineering jobs take a high level of metacognition, because though you build knowledge in a particular field for whatever discipline of engineering you go into, the act of engineering itself is really about building strong problem-solving habits, and developing a strong mental process for creation. Both of these will require you to think about how you're approaching something, which means that both of these require metacognition. And there are countless more.

Engagement

Just as importantly, it's critical to engage with information, when working in an engineering field. And for new hires, this can be hard to continually do—you're overloaded with new information, and are expected to absorb it quickly. Engaging means asking yourself "so what?" when taking in new information, to build comprehension, understanding, and assist in knowledge retention. Even if you're afraid of being wrong, when someone is briefing you on a system (or otherwise imparting knowledge upon you), leverage their expertise by trying to make some conclusion based on the knowledge they give you—see if you're right.

That sounds too abstract. How about an example (a very Portland one, for kicks). You're a new bicycle engineer working for a new Bike company, and your trainer is explaining the design of one bike model to you:

Trainer: "So you see, we decided to sell this road bike with toe cages, instead of platform or clip pedals."

You:"...which weigh less than platforms, but still give you the efficiency boost of clip pedals without requiring special shoes."

Trainer: "Yes. And it also reduces cost."

You: "Does that mean our target market is casual commuters, rather than hardcore road bikers? Serious bikers would probably be willing to spend the extra money."

Trainer: "Not exactly. We wanted to include casual commuters, but even serious bikers will want this model. Our pedals can be hot-swapped, and these stock toe cages are cheap enough that serious bikers won't mind spending that extra money, versus buying a frame with no pedals. They're getting extra toe-cage pedals, in case they want to wear regular shoes, and don't even lose the ability to use the clip pedals they already own."

Toe-cage bike pedals.

Who knows if the trainer would have even shared the second and third bit of information, if you hadn't engaged with the information you were receiving. And even though there was one part where your conclusion wasn't entirely right, it prompted the trainer to clarify that information.

Because engineering tends to be a large number of people working on the same project, it's absolutely integral that you be on the same page, and know the whys of choices made. In that way, engaging with information exercises your ability to find those whys on your own, and gives a knowledge-imparter an opportunity to impart their knowledge. This is beneficial both to you and the project as a whole, because it empowers you to do your job in cohesion with your coworkers.

Conclusion

Some of us are able to memorize loads of information without much effort. Most of us are not that way. But we can all be good engineers, because engineering is about strong habits and megacognitive skills, as well as actively engaging with knowledge.

So when you're at a job interview for an engineering position, don't be surprised if you don't know the answer to some technical questions. It's very likely that they were put there to see how you'd react when you're stumped. If you're one of the people who can memorize the right answer, good for you. But regardless, remember that your potential employers want to see you actively engage with information, yourself, and others. And they want to know that, if you ever find yourself, stuck, you will communicate with others so they can help you, so the job gets done.