Sorry I took so long to answer this. It’s a tough question!
I recently had the opportunity to witness some hiring in a Clojure company. Because we were doing a lot of web stuff, they sent all applicants a pretty sophisticated TODO list app to write using Clojure. It was separated into different parts and each part built on the last. No one was expecting them to be able to complete it. But they wanted to see how far they would get on a straightforward engineering task working independently with the documentation and other resources (IRC, etc) that they could use.
The project was basically: start a web project. Use Compojure. Use Hiccup. Get it serving a few pages. Make it talk to a database. Make it so that you can add new todo items. Make it so you can see all todo items. Make it so you can check off items. It just added a feature each time.
There’s actually 2 things you’d like to project: ability to work alone and ability to work together. Both are important in software development.
I think having a web project (just for convenience, really) that you have written yourself with the code available on GitHub is a great start. Something about the size of a blog with an interesting feature or two. Some features: undo, live preview, file uploading, recommendation engine. Mention it in your cover letter (and CV, if you need more things to talk about). In your interview, bring it up and talk about the design decisions you had to make to get it working. Talk about tradeoffs. Time to develop it is also a tradeoff. Discussing tradeoffs and design decisions is a huge marker of someone worth hiring.
The easiest way is to make some contributions to an open source project. It does not have to be Clojure, but that would help. Usually when you’re developing your solo project above, you’ll find some functions in a library you’re using aren’t documented. That’s a great place to start. Make a PR for some more/better documentation for libraries you used. Follow the contribution guidelines of that library. First patches to projects can be difficult because there’s a ton of pedantic stuff in each project, but follow through and keep going until it’s merged. You might also find some bugs or a corner case that’s not well defined. Those are great bugs. Make test cases for them. Make a PR, explaining the test, the fix, and the behavior. Make it easy for the maintainer to say yes or move it along, at least.
Mention this in your CV. If it’s not a lot, just say something like “Open source contributions in prominent Clojure libraries.” Bring it up if they don’t. Talk about how you found the bug, or your process for discovering the poor documentation. Example: “I was working on my blog recommendation engine and I needed some functionality from library X. I spent three hours trying to figure out how to get it to do what I needed. That part of the library wasn’t documented. I finally got it and added docstrings to seven of the functions in that library. I made a patch and worked back and forth with the maintainer to make it ready to merge.” Use specific numbers (like seven functions) because it is easier to see the scale.
Most companies really need people who can finish tasks. Showing that you can do that is a powerful signal. I’m sorry that what I’m saying is just “do all of this work unpaid” but you’re competing with others who are doing this unpaid. Write up something interesting about what you’ve made, publish it on a blog, and I’ll share it with my audience.