Interview Questions
I'm pretty godawful at interviewing. One path to improvement is to write my answer to some common interview questions. In theory, this practice will help my answers in real time be a little more structured.
2022-12-29
4
What follows are a series of interview questions that I crowd-sourced and my answers. I don’t expect that these questions would be asked in 100% of interviews. Rather, I expect that thinking through my answers to these questions will allow me to have more useful answers over time. Additionally, if I feel like an answer performed poorly in an interview, I can reassess these answers and look to say something more meaningful. One hope is that I’ll be able to use the structure of these answers to help me when I’m asked something that falls out of the bounds of what I’ve considered in advance.
List of questions:
- How did you get here
- Mediate a conflict
- Helping without being asked
- Personal ownership
- Bad decision
- Self improvement
- Work improvement
- Constructive criticism
- Outside your comfort zone
- Pushing yourself
- Stress
- Positivity
- Parking Spaces
- Automation
- Testing
- Pipelines
- AWS Deployment
- Hard things to automate
- Branching
- Learning a new skill
- Resource creation
- Difficult customers
Who would you credit for helping you get to where you are now?
Can you tell us about a time you’ve had to mediate a conflict in your team?
Tell us about a recent time where you helped somebody at work without being asked?
When I joined [MEGA_CORP], the React project was quite a few versions behind. The React team chose to deprecate Enzyme in favor of React Testing Library in React 16. Enzyme tests have a few disadvantages to RTL (React Testing Library). They’re more verbose. It’s easy to make a brittle test as they lend themselves to testing internals rather than UI. Of course, they’re also deprecated and will need to be rewritten.
It was in my first week when I found this out. I DM’d the lead and asked if I could install the needed libraries for RTL. He said sure, as long as I can get everything to work with the existing app. Luckily, That was extremely straightforward. I quickly wrote the tests and presented a draft PR to the team. In the PR, I highlighted a couple of the things that I’d done. I then offered via DM to host a quick walk-through of how RTL works if anyone wanted.
I left out my opinions about never writing deprecated code and how to evolve a codebase from Enzyme to RTL. I was brand new to the team. It seemed to me, given the state of the codebase and the fact that I didn’t yet know the goals of the project, that setting a decent pattern that could be copy-pasted and making myself open for questions and a presentation would be the ideal level of impact.
Can you talk to us about a project or piece of work where you feel you demonstrated significant personal ownership?
Can you tell us about a time you made a bad decision at work?
I used dependency injection when copy-paste would have been a superior solution. I try to use AHA (Avoid Hasty Abstractions) programming as a sensible default. For this project, we had three different business domains that all shared a contract view. Once in that view, the logic got complex. To untangle it all, I picked a state machine library. This would allow the team to understand what was happening in the codebase easier. More importantly, state machines are an excellent tool for communicating with business, design, and product stakeholders. The team had received a lot of bugs in this area of the codebase. In fact, these weren’t bugs at all. Rather, they were requests for subtle features and needs that we didn’t understand originally. My hope was that using state charts would solve the business -> developer communication along with helping the team understand a complex area in the codebase.
What we did was write a function that spawned a state machine, injecting the rules for the current business domain in context. This was an acceptable solution. It was at least the second-best solution in hindsight.
What I failed to think through was that state machines are new to most engineers, especially on the front end. What I should have done was used three machines, one for each business domain, and accepted the code duplication. This would have made machines that were easier to understand. Kept business rules isolated by domain and allowed for examples of state machines that were easy to understand. This would have allowed for state machines to spread more naturally throughout the organization.
What have you done to improve yourself in the past year?
My most effective strategy for self-improvement is flashcard usage. I use Anki, which is a spaced repetition flashcard application. I primarily use it for three kinds of flash cards.
- Productivity
- Code patterns
- Concepts I want to recall
Productivity is the most straightforward. When I encounter a shortcut, VSCode extension, or tool for a task, I’ll make flashcards to learn it. The current one is actually from Emmet when I want to wrap some text in HTML. Copy selection, access the command palette, type wrap, hit enter, then the tag you want (span, p, etc.). This comes in handy. The flash card was super quick to learn. But spaced repetition will keep it top of mind until it’s muscle memory.
Code patterns are a little more nuanced. I pretty regularly do code puzzles, think LeetCode, but not the hard problems. Generally, those patterns aren’t practical for my everyday work, but they come in handy. A recent one is to get all possible pairs from [2,4,6,8]. This is straightforward. When I solve that in the code puzzle (or look it up after stumbling over it), I’ll drop it on a flash card. Sometimes, I’ll remember the exact code snippet when I encounter that problem in real life. Usually, I’ll only recall that what I want is to slice the array and use the index to make the pair. So I’ll have a starting point. That fuzzy memory helps a lot.
Concepts I want to recall can be pretty broad. A decent example of this would be studying for the AWS Cloud Certified Practitioner exam. I also have decks that are more philosophical or personal as well.
Can you tell us about something you’ve taken on and improved at your work?
My current project has had some trouble keeping dependencies up to date. In this case, we can’t just turn on Dependabot and work through it, as many dependencies are more than four years behind. As a result, I started a plan to do new sprint Monday dependency updates. On Mondays, we’ll make a PR that updates at least one dependency. This plan has a few benefits.
Keeping the scope small will help engineers on our team who aren’t comfortable with dependency updates. Because our test suite isn’t robust, doing it on Mondays gives us time to smoke-test the application. Finally, this gradual approach meets the business goals of the team.
Every developer wants to move to the latest and greatest platform. I’m certainly no different in that regard. The challenge is to be able to balance the desire to work with modern tools with the needs of the business. In this case, our deprecated tools are holding us back, so updating them is a priority. However, the business needs are such that we must find a way to get us to a more modern toolchain and deliver our regular sprint work. This strategy seems like an appropriate compromise.
What is one piece of really valuable constructive feedback you have received?
Can you tell us about a time when you felt you were working outside of your comfort zone?
Learning Data Structures and Algorithms. I’m not a traditional computer science student. Nonetheless, I think there’s a lot of value
Can you tell us about a time when you or your team had to push yourself to reach a goal?
What causes you stress/negative feelings at work?
Lack of autonomy and lack of clarity.
What gives you positive energy at work?
For me, it’s pair programming. I enjoy pairing with developers of all skill levels. Pairing with newer developers is fun. It teaches me how to communicate, think quickly and clearly explain why I like a solution or idea. Pairing with more seasoned developers frequently ends up in TDD or ping-pong-style pairing. Falling into a ping-pong rhythm with another developer is one of the best flow experiences. Often, pairing with more senior folks ends up with a Miro board or Excalidraw open so we can explore possible solutions or architectures.
One of my favorite things about pairing is that it’s the most natural way to teach each other tools and productivity tips. I liberally use multi-cursor, which frequently blows a junior developer’s mind. Just recently, from another senior engineer, I learned about Thunder Client as a Postman alternative. It’s right in your editor. Delightful!
Pairing also has the benefit of building strong relationships between developers and teams. It normalizes knowledge sharing. Especially with the expansion of remote work, I’m excited to see more companies and teams get comfortable pairing.
You’ve been contracted to design a system for a parking garage that shows how many spaces are available.
Before starting, there are a few questions that I’d need to answer. The first thing I’d want to know is whether there are types of spaces. I’m familiar with garages that have long-term, resident, and short-term spaces. This would help me plan for future changes to my schema. Next, I’d want to know about expansion for the garage, as well as space type. It’s important to understand how the number and space type may change over time. I’d also need to know how this information should be displayed and consumed. Do I have a visual interface like a light board, or do I have an API that I need to respond to, like SomeParkingApp.com? Finally, I’d like to know about the pricing for parking spaces. Do I need to consider parking rates, free days, size of vehicle hours, and so on?
I like a queue or event bus for this application. Mostly, nothing is happening in a parking garage, but we can’t miss any parking events so serverless makes a lot of sense here. No need to run a server constantly when it’s only used when parking starts or ends. If we’re using a queue or event bus we can easily add subscribers to events like PARKING_START and PARKING_END. That way if in the future we want an analytics service to determine the most popular parking times, it’s straightforward.
For a quick solution to the problem, parking spots are essentially a fixed-size array. Each slot might hold an object, including vehicle type, license plate, and time parking started for example. For a query like, how many spots are available, we can just find empty slots in the array. Something else we might need is the total price for a parking event. We can look up the vehicle by its UUID (license plate) and then send the information to the payment service. In this case, I’m considering type (maybe a large pickup truck costs more) and start time. The service can calculate pricing based on the rules it has and return that to the checkout. Once payment is complete, we’d fire an event back to the parking spot service to remove that vehicle from the array.