One matrix you’ll like for your upcoming behavioral interview
Behavioral interviews are a natural part of any formal hiring process. Everyone coming out of college will have to do a few of them. It’s very likely that anyone who wants a job in general will need to do one, even if they’re going through the most common route of knowing someone in the company to refer them.
You’ve probably heard of the STAR method or SHARE method before, so we won’t go into that here. Instead, we’ll talk about a nice little grid you can fill out to help you organize your thoughts.
From a glance of the grid, you should be able to answer any question in STAR fashion. The exercise of filling it out and practicing from it (until you no longer need it) with friends or other mock interviewers almost assures strong interview performance on the actual day. You can condense your thoughts into just a few memorable topics that usually match some variation of a question ahead of time. While you might be asked an infinite range of questions, you know you’ll answer from a finite pool of experiences.
Try to recall truly difficult or interesting experiences in your career. The best ones tend to be the very time consuming projects which you and your whole team found more difficult than you initially thought. They tend to have the most depth and help you cover a wider range of questions.
Challenge(s): Problems fit well into the STAR story model. You see a problem, you did something interesting to solve it, and you improved both yourself and the project a little bit. No secret sauce here. Just talk about one problem from a prior project and practice the story.
Situation/Problem: Sub blocks had intermittent failure.
Task/Goal: Whole system should function, including sub blocks.
Action/My work: Use test probes on each connection and make a checklist of most probable disconnects.
Result: Functioning system that was easier to debug if portions broke in the future
Mistake or Failure: Oversight might be a more presentable term for this. You want to talk about an actual oversight you had, what you did to fix it, and what you would do in the future to prevent a similar misstep. Again, quick 3–4 step stories are what we want.
Situation: Spacing between conductive copper tracks (“wire”) on the PCB were too narrow in some areas, causing some parts of the signal to stop
Task: Signal should run through within tolerance and reliably connect
Action: Solder additional wiring to connect pieces. Consider spacing intently for every part of the system with equal thoroughness. Do a second order, double check the actual designs with someone, not just the simulated circuit.
Result: Communication system that could be worked with for now, and another run of boards that would make a better final product.
Leadership/Initiative: My leadership example might be an oddity. The story here is about gaining a new skill and later leading by teaching. While the process of how I learned isn’t necessarily a form of “leadership”, a story about how I just taught someone how to wire a transmitter-receiver system is like an incomplete sentence. There needs to be some kind of arc.
Situation: No communications experience between the 3 of us.
Task: We had to create a software interface for communications. Could not be independent. Software limitations would inform hardware specifications.¹
Action: Googled videos on how people set up the wiring for basic communication protocols. Studied different code structures to understand the functionality required for a transmitter and receiver. Familiarized myself with I2C, SPI, and how a general communication protocol would work. Tested different sub-circuits on a breadboard.
Result: Understood enough about common software patterns and hardware designs to wire and program two microcontrollers to send signals between each other over a power line and teach the other team members how to do this as well.
Conflicts: Conflicts are natural (as is every column in this grid). Good stories are ones about simple disagreements that end up with neither initial party as the “correct one.” This is because being right all along in your own story might come off as conceited (or worse: untrue), and being wrong might come off as too inexperienced. On the other hand, if nobody was correct, then everyone gained something from the eventual correct action, and you’re the hero for helping us get there. Choose impersonal conflicts with open ended solutions. Examples include: Choosing between price and quality or tie-breaking between two equally qualified candidates.
Situation: There are disagreements on design choices
Task: One design needs to be selected
Action: Solicit more opinions, go with the most physically sound design. In a work setting, also consider the impact to other stakeholders, and the potential costs. Don’t bother more than 1–2 experts since their time is likely valuable
Result: A design that is objectively sound, not chosen through any personal preferences.
What I enjoyed: This is the easiest one in my opinion. You’re just talking about what you liked. It’s not all trick questions and most interviewers will be genuinely interested in some of the stuff you may have worked on in the past. This one doesn’t fit STAR, and it would be kind of forced if you tried.
What I would do differently: This functions as the “Result” in every project you’re talking about. It also answers any questions related to self improvement or understanding shortcomings. It’s also something you should ask yourself pretty frequently (or something you ask yourself too frequently already).
Other questions: While this will help you with about 90% of questions, this isn’t a perfect Encyclopedia. You might want to still have custom answers ready for curveballs like: “What would your friends say is a bad thing about you?” or “What was the worst part of your last job?”
- Strictly speaking, selection of gain, bandwidth and baud informed hardware specifications. These are physical limits akin to a more tangible tradeoff like versatility vs portability of a pocket knife.
