The Unconventional Interview

I took part in what I thought was a rather unconventional interview recently. First, I was asked to bring my laptop, which I don't normally do. Then, after the interviewer asked me three or four general questions about my background, he spent about 45 minutes outlining the documentation issues and challenges that need to be solved in his environment. In general, information on a number of algorithms / APIs is scattered in various formats and difficult to find. He then asked me to diagram how I might go about solving the problems -- and said he had another meeting to go to and that he'd be back in an hour.

After getting over my momentary surprise, I determined that the primary issue was standardizing how information was presented and made available to the various user audiences. At the highest level, non-technical users need to find algorithms that solve specific problems, for example, identifying individual's names that are blacklisted in specific languages and countries. At the lowest level, developers need to know for a specific algorithm or API the compliance or legal rules it solves, the team contact info, update history, and so forth.

Based on the high-level information he'd provided, I outlined my thoughts in three areas: Assumptions, Business Process, and Information Architecture.

Among the assumptions, I suggested standardizing on an existing platform: Confluence (though not my first choice if starting from scratch).

For the business process. I proposed posting business requests publicly, allowing all stakeholders to contribute to analyzing and scoping the work. This would also allow interested parties to validate that the technical features delivered provided the specific benefits identified in the original request. And the information produced could be used as a basis for documentation.

For the information architecture, I outlined several levels of documentation for the various audiences. For the non-technical audience, provide a high-level statement of the project's scope, goals, and audience. The algorithms were grouped by functionality, so it made sense to provide an overview of each group. This information needs to be made available to third-parties who cannot for security reasons access the internal site. I recommended exporting the info to a PDF that can be shared as needed. For the developers, I suggested adding META data to the algorithms so they could be found using a sortable / searchable index of all algorithms.

When the interviewer returned, he seemed surprised to see what I'd written on the white board. He said other candidates had completed the exercise on their laptops and emailed the diagram to him. He hadn't given me any such direction though, and I knew I could work more quickly and fluidly on the white board. I suggested he take a picture of the board, which he did.

What do you think of this interview process and of my response? (H/T to @SaleemQadir who suggested I share this on LinkedIn.)