On Interviewing
Last updated
Was this helpful?
Last updated
Was this helpful?
Typically I try to prepare a number of stories from the top projects on my resume which are flexible and varied enough to fit into any number of behavioural questions an interviewer might ask. A reminder of some key projects and stories:
Ada
Pitching/presenting the mimic project idea
Ada
Intense HW debugging story
LIAP
Supply chain management with STMuCs
LIAP
Group member 1-on-1 regarding poor work
Motor
Getting Kicked out of the machine-shop
Here are some common which you can use for practice.
Situation: Sep 2021 - April 2022 I was working on my capstone project LIAP is... The plan, which had been approved by our client, was to... As you might recall we were suffering from a global chip shortage in 2021! What happened is that our first round of manufacturing got pushed further and further back because we were simply not able to source our MCU
Task: The problem was that we had this seemingly insurmountable bottleneck because we couldn't source an essential component and our set plans which we had discussed with our client were caving in around us.
Action: In December we came together at our weekly meeting and we finally decided. OKAY things are not looking so good. Let's come together and form a plan. The plan was... I will also mention that before we started to execute on this plan we did schedule a meeting with the client in order to communicate the changing situation and pitch them on the solution we came up with.
Result:
Takeaway: Just because something has a low likelihood of success doesn't mean it isn't worth considering. -> In that batch of capstone projects we were one of only a few that were able to deliver a physical product. That really made us stand out a lot. At the same time, make sure you have some fallbacks/mitigations just in case. I slept a lot better knowing that we had these cheaper MCUs on lock in case we needed them.
Situation: In January 2020 I was working on a student project to build a BLDC motor and motor-controller board. We divided our team of four into two teams of two: one group to handle the design+manufaturing of the motor itself and one team to handle the electronics+software
Task: I was on the hardware team Aside: one really satisfying 'trick' I pulled was that the machine shop would charge for waterjet cutting services by the individual item not accounting for the complexity of the item itself. So what I did was pattern the same item many times and connected each individual piece by a tiny little sprue. After receiving the parts I would then take them to the bandsaw + grinder to separate them and file them down -> We saved like 1/10th the cost or something like that. ANYWAY: One day I was in the machine shop just looking for some hardware to bind some components together AND I didn't put on my safety gear (steel-toed shoe covers, eye protection) AND the machine-shop head happened to walk in and see me AND I got banned from that shop That's pretty embarassing. The machine shop was pretty important + integral to the work I had to do for that project. I had had to attend a safety workshop to get certified to even go in there in the first place.
Action: First step was doing the rounds of accountability to the various people that this event affected. I talked to and explained the situation to my hardware team-mate. I explained exactly what happened, where I went wrong, and how we might have to restructure our work if I wasn't going to be let back into the machine shop. I also repeated that explanation to the team as a whole including potential solutions I had discussed with my hardware team-mate and how those solutions might affect the group project overall. I made sure to not deflect the blame: of course this was my mistake and any negative impacts of my mistake should be reflected in my final grade relative to theirs BUT I think that because I owned up to my mistake in this way we were able to focus on possible solutions or work-arounds to the situation.
Result In the end I was able to meet with the machine-shop and apologize properly at which point I was allowed back in to the lab. SO everything worked out alright in the end.
Takeaway My main takeaway was that when you make a mistake. You should admit your mistake, communicate what you did clearly, and also own it (accept the blame). By doing so you create space within the team to focus instead on how to mitigate the shared consequences of your actions.
Situation: During the LIAP project a team member was falling behind and becoming disconnected fromt he rest of the group. For context: this group was run fairly loosely. We had mapped a large overall plan and checked in with each other stand-up style once a week but other than that everyone was free to complete their work at whatever pace they wanted. This worked because it was a group of pretty independent people who were capable who were capable of creating their own structure AND coordinating appropriately with one another. This person: The work he was doing didn't seem to be making much progress, he would miss weekly team meetings and he would mention completely different work during team meetings as opposed to instructor meetings
Task: At a certain point I decided that we needed to do something about this.
Action: I brought up the issue with the other members of our group I started out by establishing consensus, we did all perceive this group member to be drifting away from us I directed the conversation towards what outcomes people would like to see (turns out we mostly wanted this person to get on the same page as us again and start contributing) In light of those goals I started pitching some suggestions to see if the rest was on board (i.e. would we be willing to create a list of concrete tasks that we could assign to this group member? how far would be wiling to escalate if things don't go well? etc.) I then proposed that I would go talk to this group member 1-on-1. Therefore I was able to talk to this person fairly gently (present problems as concerns rather than accusations, present solutions as "how can we help?" rather than "Hey you're going to do this now")
Result: The outcome was really positive. This person opened up about feeling like they were struggling a bit and they were receptive to some of the potential ways in which we could do things going forward and they eventually got back on track.
Takeaway: My takeaway, again, is that communication is very important. If I had not talked to my team before going into the 1-on-1 I wouldn't have been able to offer the support that I was able to offer because I wouldn't have known what my fellow group members were able to do. ALSO: perhaps this is my personal style. but I do think that workplace conflict is better resolved through collaboration and understanding rather than punitive measures
Repeat the question. Ensure that you understood it correctly. Also seek specificity. What was left out of the question that you think will be relevant? If the interviewer responds dismissively you can demonstrate why you think a particularity is relevant with counterexamples i.e. "Well if the data is arriving as a stream I structure like this and if it arrives in large packets I would structure it like that".
Spitball multiple approaches. Start with the simplest brute-force method you can think of and vary things from there. How can you make it more efficient? Discuss the merits and limitations of each solution that you come up with.
Select one approach. If possible you should gain approval from your interviewer i.e. "How do we feel about proceeding with this approach?".
Write it. Speak aloud and write comments as you go.
Review it. Start from the front and rubber duck each line as you go. If you find an error explain why it is an error and mark it off. After you run through your code come back to each error and propose a solution or several solutions before implementing one of them.
Write some unit tests.
Conclude with some analysis of the overall solution. What is the time complexity? What is the memory required? How would you modify it for scalability (i.e. streaming input data and/or input is too large for your system memory)?
Below is a procedure for coding interviews which I have synthesized from a couple different .
Also consider checking out . My understanding is that this is one step up from the coding interview.
Also also consider potential employers.