Skip to content
2 min readDean Keinan

Naming the Nouns

Fun and games in domain analysis

Here's a fun game to play with friends and family.

Consider some unfamiliar business:

Traffic cone logistics

Say you've got 90 seconds:

  1. Guess a few nouns. What objects, events, concepts, or stakeholders probably exist in this world?
  2. Bonus: What might the stakeholders care about? Who has something at stake? What creates value for them? What can go wrong?

Traffic cone logistics

In the early days of Finch, we added a data modeling interview to our onsite for engineering candidates. The format was straightforward: given some product we want to build in some domain, let's whiteboard for 30 minutes about how we'd model it.

We knew we'd be rapidly expanding into new workflows, each with its own vocabulary, rules, and inconvenient distinctions. Whatever we built first would change, and engineers would need to make sense of unfamiliar corners of our business.

A few months into technical recruiting, we had a streak (~10) of rough outcomes in the data modeling session during onsite interviews. We had repeatedly debriefed (and passed) on candidates who had otherwise strong showings in the other sessions of the day.

We evaluated the session holistically. We examined failure modes, our upstream technical screens, and questioned whether the interview was providing the signal we were looking for.

A couple of questions were posed for discussion that nagged at me:

  • Are we overvaluing schema-design? One thought was that a segment of strong engineers (particularly those from larger organizations with mature data models) had rarely needed to develop this skillset.
  • Is our subject domain too niche? The thought here was concerns that given the time allotted, it wasn't realistic to expect a candidate to grok an unfamiliar business.

Naming Nouns

As a resident schema pedant, I was compelled to naively prove what emotionally felt true to me:

  1. the bar should stay high
  2. it wasn't just about schema-design
  3. nothing about our domain was an outsized challenge.

So I concocted the above straw man of a game. To make my point, I circulated it around the office to my (exceptionally talented) non-technical colleagues; unsurprisingly, all among us could play and "win". (Where winning is making a plausible educated guess)

It proved basically nothing, but it crystalized my perspective: The session is more than an evaluation of database experience.

Given thirty minutes with a subject-matter expert, can a candidate construct a plausible ontology from incomplete information? How do they discover the domain in the time allowed? Do they propose concepts, test distinctions, expose assumptions? Do they opportunistically revise the model as they learn?

Epilogue

Adjusting our upstream screens to evaluate a little data modeling resolved our issues.

Eventually, our streak of rough interviews ended, and we found and hired great engineers. (and are still hiring!)