I recently had a job interview that, frankly, baffled the hell out of me. It started out well enough: he had a VC backing his new "spreadsheets as a service" software model, had $2 million in seed money, and was looking for developers to help turn his prototype into a product.

I worried a bit. I'd interviewed at Airtable three year prior and gotten turned down because of my patents. I designed the prototype for what is now Splunk's dynamic dashboards with dataflow subdisplays; it was an application of the Fundamental Algorithm of Spreadsheets to a dashboard (the relationship of the spreadsheet's grid/cell system to the directed acyclic graph underlying how data gets updated). Airtable didn't want to piss off Splunk, despite the patent being wholly defensive and probably defeatable with a prior art argument.

But as we talked I started to wonder just how much he knew about the field he was stepping into. Not financially, but technically. Because this guy had just not done his homework.

He started talking about a component system for populating the cells of his spreadsheet, and I started talking about how elements could be identified with a three-field object identifying the type of object (so not just what table/database it was in, but also how to render it), the ID of the object (the specific row in the database), and the properties for each field in the row. He started to get excited and was writing things down when I mentioned that I'd just described both Project Midgard and the Block Protocol; the things he wanted already existed.

Worse, the things he wanted are so standardized already that the W3C committee has provided for them in HTML already; the DOM accepts itemtype, itemid, and itemprop for those three elements. These triples are everywhere: table/row/column (SQL), sheet/row/column (Spreadsheets), database/object/field (NoSQL), class/constructor/field (Object oriented programming), tag/attribute/element (Web components). He had no idea.

He mentioned that he wanted to be able to nest spreadsheet cells inside one another, to create supportive structures where "a cell" was busier and more complicated than just a single calculation or value. I mentioned Vissh and Noah, a pair of research programs that had investigated exactly that. He had never heard of them.

It just went on like that. He'd never heard of Peter Sestoff, who wrote the book Spreadsheet Implementation; saying you want to implement a new spreadsheet engine and not knowing about Sestoff is a bit like saying you want to learn how to cook but have never seen a cookbook.

At one point he said that one of the bits of special sauce he wanted was speed, and he would get by having the system in a completely consistent state, but that cells that weren't visible to the user wouldn't have their code run until they were scrolled into view. "So, like Build Systems a'la Carte with one of your build triggers being 'within the viewport?'" I then had to explain that Build Systems a'la Carte was a foundational paper in systems like the one he was describing: output cells exist to show calculated values, and those values are recalculated on build triggers, traditionally "some cell that is or is a precedent for this output cell changed," but adding "and can be seen by the user" would be interesting to code.

He seemed... rattled. He asked me why I knew so much about spreadsheets. I shrugged. "I don't, really. I'm more interested in programming language theory in general. I rarely use spreadsheets; I think they're ugly and I don't handle the wall-of-data thing well; I tend to be more linear in my thinking." Which is hilariously half-true, given that I have a strong philosophy of table-driven design in code. "I've just read a few things through the years."

He didn't hire me, and I can't help but feel like I gave him a thousand bucks worth of consulting during our interview. But I'm still boggled: how do you raise $2 million and not know anything about the technology of the field you want to "disrupt?"