Clojurians Log v2

Definitely multiple pros/cons for having a "homework" round. One more to consider: I've seen programmers take between 2 hours and 20 hours on the same piece of homework - so homework from candidates who get can get the job done quickly (possibly because they are more practiced in Clojure) doesn't necessarily stand out from homework from candidates who struggle but just spend a lot more time and effort on it. We don't have set homework where I work at All Street and I think it makes our interview process better for candidates & assessors.

I like companies that give you alternative of take home task vs giving a presentation of some code you already wrote, like a OS (or otherwise hobby) project. But of course with this approach assumes is that the “take home task” is just a starting point present, review and discuss some real code with the candidate and understand their choices etc. Which in my opinion is much more valuable than checking if someone can write fizz-buzz or a helloworld restful service..

having said I’d much rather prefer the approach described here and that’s more or less what we do at Kevel. The advice above was for the case when you really have to have an interview with code on the screen https://clojurians.slack.com/archives/C0KL616MN/p1619018912073900

@trailcapital I think that as @hmoorefarley said, it's pretty common to have home assignments taking a lot more time than expected. I think that one way to address this is to curate carefully what kind of exercise must be present as options and test-drive with someone inside the team so that you can verify if it's still possible to solve it in the proposed timeframe.

our take home is fairly open ended. We do specify that no candidate should spend more than 4 hours on it - and that it is fine to submit something incomplete w/ a paragraph or two of what they were going for. Of course, there is no way to stop people from going ahead and spending 20 hours on it

I think we do a good job internally of equally valuing completed take homes and incomplete take homes, but of course the candidate will assume a completed take home == better impressioon

Yes, this is why it's important to be a narrow problem. Nubank has a roll of pretty simple exercises that capture the essence of their business and allow everyone to solve a problem as straightforward as possible. They tend to strip web APIs for instance, too much boilerplate, and focus on simple data processing using simple standard IO, at most.

For instance, "given that you have a bunch of json-lines in a file, each line representing a transaction, give-me some sort of result..."

Better than ask for a fully implemented web api. Anyone can make web server boilerplate. I think that the main objective of a test is to verify if a developer can: • Understand the requirements of the problem at hand • Communicate with the team about doubts, given that in real-life business requirements are ambiguous • Develop a proper solution using best practices as tests, segregation of IO logic, etc

And you can do that even if the problem can be solved in a REPL gist