What I learned from a take-home code challenge

Posted by Elf Sternberg as Lab Notes, Today I Learned

I’ve just spent the past four days working on a “homework assignment,” a coding assignment given to me by ${MEGACORP} to assess my skills as a web developer and programmer. I was sent a zip file with a README in it and a pair of sub folders: one of the server, one of the client, and told to build it out and “make it work.”

It was broken as delivered. The install worked fine, but I winced when I realized that yarn had installed 2,572 different packages in the library trees, including the entire flow binary and the OCaml runtime that comes with it! Running the server threw a dozen errors, and the client showed only a blank white page with a red notification bar, completely unpopulated.

I was coming out of Splunk, where I’d been working with Splunk’s own server and client foundation for five years. That foundation was built on top of Django and Backbone, two skills I clearly had when Splunk hired me in 2013. In 2015, some of our teams had started to work with React, and I’d been fortunate enough to be part of that.

But the 2017-2018 development cycle had been all Go, all the time. I was woefully out of practice as a web developer.

Here’s what they threw at me:


GraphQL is a query language specified by Facebook that handles client/server transactions. You specify the possibly deeply nested data you want sent to the client, and when you make the request you get a JSON object pre-populated with that nested data. Instead of assembling all the data out of different requests, your client sends a single request and gets back all the data it needs to fill in a page.

It’s a pretty good idea. But it was new to me.


Yoga is a proxy server into which you define the GraphQL endpoints for your client. You write your specification here, defining the structure of the data and the handlers for assembling that data out of your back-end. Also completely new to me. You write in Javascript or one of its derivatives (Typescript, Clojurescript).


Prisma is yet another proxy server, this one written in Scala. Prisma is the big aggregate engine; it talks to all your back-end services and assembles the data for you.

The relationship between Yoga and Prisma is basically something of a firewall; Yoga limits the kinds of transactions that can happen, and has the capability to restrict access based on authentication issues. Prisma will take whatever Yoga sends it and do the heavy lifting of assembling and aggregating the objects to send to the client.


JavascriptWebTokens were being used for authentication. I straight up admit that I ended up using them badly and contrary to security advice. We hadn’t used them at Splunk until the “cloud era,” and by then I was working on Kubernetes deployment issues and didn’t get to learn much about them. They’re basically cryptographically signed bundles that describe “claims,” a word that encompasses authentication and authorization, but they’re short so they fit in the HTTP Authentication: header. Unfortunately, they’re also blatant, so if you’re using them in an unsecured environment anyone can grab them and use them against you.

ES6 Javascript

Oh, and did I mention that this was entirely ES6 Javascript, which we hadn’t been using at Splunk at all? So I got to learn a whole bunch of new things! And actually, I was pretty stoked about that. It has real Classes now, and the function shorthand operator with no this overrides (inhering the lexical this is awesome!), and it does destructuring and lexical naming and a whole bunch of stuff that I enjoyed the hell out of it.


I wasn’t new to React. In fact, I had a pretty solid working relationship with React, and even had a good idea of how to hack it to use with older, Backbone-based data sources. But that was two and a half years ago, and React has moved. There are more libraries today.


Apollo is a toolkit for GraphQL clients. The Apollo toolkit creates React Contexts in which you can write GraphQL queries and get them back as processed objects ready to feed directly into your React components and draw them at will. Apollo was interesting, but I found its relationship with React a bit awkward, especially when trying to handle post-event routing. Apollo wants to deliver you ultimately render, but in some cases, such as log-in, what you want is both the render event and some other behavior, such as dismissing the login pop-up. That was tricky.

Material & Material UI

Material is Google’s own CSS Design System, the one we’ve all come to recognize. It has paper and cards as metaphors, and has a whole bunch of guidelines for building out the best UIs. It’s fine as far as design systems go, and it’s certainly mature.

Material UI is an implementation of Material in React; it provides a whole bunch of widgets for all the things one might normally do with an application and makes them easy to bring to life.

… and that was just the basics. I had to learn all of those enough to do the job, and this was for a code quiz. It was like a 32-hour whiteboarding session without any of the “cultural fit” stuff going on. It was grueling, and I hope I don’t have to do anything like it very soon.

Part 2: What I actually did on the project.

Comment Form

Subscribe to Feed



May 2019
« Apr