I had a similar assignment when I applied for a remote Clojure job at a startup in California. Create a REST API in Clojure (which I can do in my sleep at this point). I decided to use a database (in my case, H2) along with HugSQL because it handled some of the requirements for me (unique constraints, etc.), and I'm comfortable with databases. I could have done it in code using a collection (and used filter/map/reduce/etc.), but just using a database and defining a schema seemed the simplest and most fool-proof solution (and I think the proper place for these sorts of checks is in the database, anyway).

During the code review, the interviewer seemed surprised that I used a database, but didn't seem to have much of a problem with it ("you're the only one I've seen do it that way"). In any event, the 'code review' consisted of him saying "Well, um.... I can't really find anything wrong with this, you're definitely a good Clojure developer"

And then they passed on me anyway. I wonder if they ever filled the position?

P.S., not the first time something like this has happened to me, I've had nearly the exact same experience when I applied for a Golang job.

P.P.S., Also I've got the "Pass. We think you'd be bored here." Which is aggravating. It seems I can only find employment at places with nearly non-existent tech screening that under-utilize me and don't care if I'm bored out of my skull.

HugSQL is very handy - used it for my solution also.

Coming from Django Rest Framework I felt at home with Compojure-API.

Hearing "you are overqualified" is awful.

Not being a Clojure dev I'm curious: Wouldn't a database be the more scalable solution? How would multiple servers share access to the data of it's in memory? What about persistence?

It was an 'exercise' for evaluation purpose. In the instructions I was told that a database was not necessary (I'm assuming the interviewer didn't want to have to setup a DBMS just to evaluate my solution).

The obvious solution to me in this case was not to eschew the use of a database. Since Clojure runs on the JVM, there are many 'embeddable' databases one can use (H2, Derby, et al) that do not place a burden on the person running your program. Hacking together a poor implementation of an in-memory database myself seemed silly.

Indeed, a major use of embedded databases like H2 and Derby is in prototyping - with the intent of moving to a 'real' database in production.

Having 5 years professional experience with Clojure, I applied a few months ago to a remote Clojure job, and the coding test was none other than recursion via zippers, literally my weakest point. I could have done the job just fine since they said they didn’t use zippers on the job, but failed the test and they passed on me. Coding tests are the real problem. I’ve had some great ones where you can tell someone put effort into it and will review it fairly, and I’ve had some that were hacked together like this one where it’s clear they weren’t given enough time to put it together by their superiors.

Coding tests aren't always the problem, but coding tests that evaluate skills the company doesn't even use? That's just disrespectful.

Zippers! This is definitely a knowledge gap for me; thank you for putting a name to a thing that I've encountered in the wild.

Here's a good article I've found with information about them:

http://josf.info/blog/2014/03/21/getting-acquainted-with-clo...

Yea, a proper technical interview needs have more breadth to mean anything. This question is pretty dang close to esoteric language features trivia. Which would have flustered me when I was young, but now just makes me angry and I'd probably (want to) launch a dry-erase marker at your head.

There is also the issue of nervousness that comes up at coding interviews. See "Embarrassing code I wrote under stress at a job interview":

http://www.smashcompany.com/technology/embarrassing-code-i-w...

During one of my first coding interviews I used a goto. I simply forgot about the existence of loops I was so nervous, but for some reason the archivist in the back of my brain responsible for preserving my childhood Apple ][ BASIC knowledge stepped up and said "I got this."

That’s pretty funny. Did they really not mention anything about using an atom when they sent you the assignment?

Maybe if you had used datomic as your database it would’ve been fine (/s)

The first assignment was writing an algorithm for managing a job queue according to some precedence rules involving job and worker properties. Input and output were JSON formatted data over stdin/stdout and my solution used native collections and car/cdr style recursion.

They said it was OK and asked me to turn it into a REST web service as the second part of the assignment. Now I had to keep score between calls but sharing data using a global structure goes against every fiber of my developer muscles so I picked a database. I'm no clojure expert but I guess in the real world most REST APIs are using databases under the hood instead of atoms.