Clojurians Log v2

https://m.signalvnoise.com/hiring-programmers-with-a-take-home-test/

I guess that's one nice thing about Clojure vs a Ruby or JS shop. I've never had the problem they talk about in that article of sending out 20 screening exercises for one opening.

There are Clojure opening with homework and live coding exercises for sure, no idea about relative frequency of course

I would also not feel so great about life if I sent out something that took 3-5 hours (and double that (???) for successful candidates) to that many people with a lower acceptance rate than Harvard.

It's enough to make one contemplate self employment!

I've done 3 homework assignments and 5 or so live coding challenges this month, passed them all, and I'm still hunting 😆

My Clojure hiring process eventually involved a take home exercise, yes. Although I gave candidates a choice: take home test, do a test on-site with their own equipment, or do a showcase of some project they built. Interestingly enough one hundred percent chose the take home test.

Really? Oh man, I would love to show off an existing project 💯

Something I've put hundreds of commits into instead of dozens

I'm glad no one chose that route because that would have been the hardest for me.

In that it would have required the greatest amount of preparation, and the most thinking. With my exercise I control things to make sure it gives me the answers to questions that I'm interested in. There are all kinds of projects where maybe they're not dealing with the type of design decisions that reveal what I'm looking for, or they're in a domain that they understand way better than me so I'm not equipped to evaluate.

On the other hand, it gives you the opportunity to see what their code really looks like, outside of a evaluation context, and most homework projects are basically trivial, since they have to be completed in a day or so

I don't think my approach generalizes very well though. This was in a situation where I was not only making hiring decisions, but also a lot of technical and architectural decisions. I had gotten the team aligned around design philosophy and code style, and so the questions I was interested in were things like: is this person going to be able to keep up with the team? Are they going to be on the same page with how we do things, and how expensive in terms of time and energy is it going to be to get them on that page?

These days I'm less hands on and in a non-Clojure shop, so I wouldn't use that process. I actually don't know what a good general purpose approach is.

I think I would have been much happier if a more junior candidate did a project showcase rather than a more senior one, probably. I found that it's more senior candidates that you have to be wary about - if their mindset is too far from what you're looking far, that's more difficult/impossible to change. Arguing all day with someone to get them to write code the way the rest of the team does is a nightmare scenario.

> if their mindset is too far from what you're looking far, that's more difficult/impossible to change. Arguing all day with someone to get them to write code the way the rest of the team does is a nightmare scenario I've been through that and that is certainly very tiresome (especially psychologically). I actually appreciate people that have strong opinions, but they should be open to listen to others and change them. I would say that the problem is not being senior, but being "stubborn" (though I can see how these two go hand-by-hand). I'm open to re-evaluate the way I think and I believe that's the only way to evolve. But, this has to happen in the right time and place, and for the things that actually provide value to the business. Arguing about every single minor different way that something can be written (be it even syntax) is not productive. This is something that actually differentiates someone with a long history from someone with experience that is actually senior. Being senior is not just about knowing the technical aspects, but understanding the business implications of the technical choices.