Author: Ieuan

Ieuan Skinner

February 3, 2021

Technical Challenge Approach

Shwmae! I'm Ieuan the newest software developer at the Legal Innovation Lab and in this blog post I'm going to lay out the process around my hiring and the approach I took to the technical challenge. If you would like to see my technical challenge implementation you can find it on Github here. An obvious albeit important point is that Git (and GitHub) are used by the lab to version control all their projects so demonstrating knowledge of this technology and platform are a must which means you should be clear and professional in your commit messages, don’t have dozens of commits labelled “Fix” or “Change”, treat this project as you would any enterprise software project.

Documentation

For this project the README file is intentionally thorough as many of the labs projects are open-source, open-source projects are intended to be read, used and adopted by others and so all the relevant information needs to be captured up front, you can’t rely on external sources of documentation or the project being clear to you as you are not the intended audience. Demonstrating that you understand this and can implement a clear and thorough README will be a big win.

The structure of the README is also very important, I begin by outlining the intent of the project along with the core technologies used, following on from this are instructions on how to run the project followed by a limitations section and a key features section. The latter of these is very important as it allows me to highlight all the functionality I’d developed for the task which if I don’t do means small but important details could go unnoticed such as the incremental loading or the OpenAPI integration.

Implementation

For my implementation I opted to extend an existing project the lab had already developed: the expertise directory

My reasoning for this was that in the timeframe of the challenge I knew I could implement all the functionality of this project as well as certain “enhancements” that I thought were missing. For example, the existing directory does not highlight your matched keyword meaning as you type it can sometimes be unclear why the results you’re getting are what they are without scanning through every word, I also noticed that the JSON data for the directory was loaded as an entire block on page load which meant scalability would become an issue i.e., as the directory grows so too does that initial JSON payload and so too does the load time for the directory.

Noticing considerations like these which broadly fall into the categories of UX and Performance when you're developing your implementation are worth noting down as they make for good discussion points when it comes time to be debriefed on your implementation.

A final tip for your implementation is that a fully realized project is far and away better than a grand project that remains unfinished, taking the time to demonstrate you can write clear and useful unit tests for your code is a much bigger win than having loads of untested code. Being able to host your application on a cloud provider such as Google Cloud or Heroku to demonstrate knowledge of this aspect of the software stack is also a much bigger win than a project that can only be run locally as is being able to setup repo workflows using GitHub actions to control certain events your project requires such as scraping and indexing data as my implementation did.

Debrief

The final part of the hiring process is the technical debrief after your implementation has been submitted and reviewed by the development team. It’s worth noting that the point of the debrief isn’t to criticize and/or scrutinize a candidate personally but rather to get a feel for how they approach software, never get defensive in a debrief in fact the best tip I can offer is as you’re coding your implementation ask yourself “What could I do better? Where are the pitfalls?” this way you’ll be prepared to answer these same questions should they be asked by the developers.

My own experience of the debrief was very positive, I showed the team my implementation and talked about the various pros/cons even suggesting many cons myself and the rest is history from there on out.