Job hunting, interview process and anything related to the experience of a job writing the Clojure language.
mg 2020-04-30T15:49:00.157200Z

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.

Michael J Dorian 2020-04-30T15:50:45.159200Z

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

mg 2020-04-30T15:51:00.159800Z

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.

Michael J Dorian 2020-04-30T15:51:44.160700Z

It's enough to make one contemplate self employment!

Michael J Dorian 2020-04-30T15:53:05.162400Z

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

rhinocratic 2020-05-03T23:22:40.181600Z

In a similar situation here, and seriously wondering whether self-employment might be preferable. With Clojure jobs being considerably less common than hens' teeth (at least in my neck of the woods), it's starting to seem like the sole alternative to ending my days in Blubland.

rhinocratic 2020-05-03T23:24:22.181800Z

Hope things pick up for you soon, @doby162!

Michael J Dorian 2020-05-03T23:25:15.182300Z

Thanks! You too! It's a good time to have a job at all right now :simple_smile:

mg 2020-04-30T15:53:33.163Z

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.

Michael J Dorian 2020-04-30T15:54:02.163400Z

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

Michael J Dorian 2020-04-30T15:54:28.163900Z

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

mg 2020-04-30T15:54:45.164300Z

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

mg 2020-04-30T15:58:26.167Z

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.

Michael J Dorian 2020-04-30T16:01:34.171800Z

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

mg 2020-04-30T16:01:57.171900Z

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?

mg 2020-04-30T16:04:00.173100Z

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.

mg 2020-04-30T16:12:35.176900Z

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.

Ivan 2020-04-30T16:58:26.180800Z

> 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.