pixelated heart
git push -f

Software Enginering Interview

A proposal for an effective software engineer interview.

Outline

1. Intro

Interviews are hard, because you want to interview the human AND verify they have the technical skills they claim. There isn't a standard "corpus of knowledge" and even best practices vary hugely depending on the perspective.
"whiteboarding" interviews are generally ineffective, mostly because they don't mirror how engineers solve actual problems, they're too low level. Large take home exercises can require large amounts of time to complete which is a questionable ask.
"whiteboarding" design exercises are also too low level. They don't have concrete reference and are usually meandering over simplifications.
What are we really trying to understand and can we model our interview to ask that?

2. Interview goals

We want to know:
  1. Does the candidate have fundamental technical skills to write code?
  2. How does the candidate write code, such that it is testable, scalable, and maintainable?
  3. How does the candidate approach problem solving?
  4. How does the candidate communicate solutions to their teams?
  5. How does the candidate define technical strategies that align work across long timeframes?
Since there isn't a "corpus of knowledge", because best practices vary so greatly, writing software is closer to an art than an engineering discipline. A great software engineer understands that the way they write code must solve the problem at hand, in such a way that it creates structure that can be inferred by other engineers, and can scale to change.
A good interview asks the candidate to write code so that:
  1. A fundamental skills check is complete.
  2. The candidate has an opportunity to talk about their approach to problem solving.
  3. The candidate has an opportunity to discuss their strategies for crafting software with a team.

3. The challenge

  1. Create a screen that is part of a larger application, assuming routing.
  2. The screen will fetch some item data using the routing parameters to get the profile ID.
  3. If there's no ID, show an empty form, otherwise populate the form with fetched data.
  4. User can update form and save to persist the item information.
  5. Item has a color value, allowed values are returned by the API using value type.
  6. Hovering over value should highlight it in the allowed values.
  7. Clicking value should update the temporary data.
  8. Save/Cancel buttons should only show when there have been changes.
This tests:
  1. How the candidate thinks about boundaries and ownership of data: Routing state, Server state, Ephemeral state
  2. How the candidate thinks about data structures and providing crisp type representations across boundaries
The other parts of the challenge are contrived to mirror real world situations, where there's almost always some messy product requirement.