CameronBarre

TLDR:

I don't use coding exercises in any capacity to hire junior developers onto my remote team of freelancers.

--

When I hire Clojure juniors, I have a set of questions that I've put in the job posting that they will have answered prior to me speaking with them.

I still speak to the person if they completely ignore the request to answer the questions.

There are probably 20-30 questions, some are objective, others are subjective, and a lot of questions are meant to evoke somewhat passionate answers, or at the very least, allow someone to display their passion.

Some have to do with qualities I would expect a certain type of clojure developer to posses.

Others have to do with the shape of our system, such as specific questions about tools in our stack.

The last variety are questions to gauge where on the spectrum of learning someone is at in regards to specific software development topics and practices.

I never disqualify candidates who don't have much experience with our stack, all I need to see (in their github repo) is that they write Clojure competently, and I need to understand from speaking with them and reading their questions, that they are a competent and interested individual.

I give most people I speak with a fair shot with the intention of improving my team's on-boarding process, which hopefully improves with every successful new hire, in other words, they bring the core competency required to participate in our environment and we fill in the gaps with respect to our architecture, methodology, and our stack.

Do you have to go into the office or do you work remote?

If it works for you and acts as a means to your end, you've won the game!

If you're addicted to learning, reading papers!

Structuring software as a series of processes separated by queues in the small and large.

This is situational and will depend entirely on who you work for, who you work with, and the nature of the organization as a whole.

I started out as a freelancer put in charge of the organization's data operations (getting data from point A to point B with processing in-between). I took the legacy system and transformed it into the next generation of data processing tooling. Slowly the situation morphed from me doing all the work (platform and handling business requests with the platform) to bringing on team members to start carrying the vision forward by taking parts of my previous responsibilities.

The high level is that one teammate now takes on platform improvements, and two others handle business requests.

The person I report to is responsible for the broad cultural structure of our tech team. He put me in charge and gave me full autonomy of half of the technical enterprise (the other half is an internal web application produced by two other teams).

Independence and autonomy are important qualities to allow your teammates in a remote environment (for data operations, anyway), this does require finding teammates with an adequate level of competence and agency when hiring.

I find that 1:1 chat based communication creates a casual environment which leads to an easier formation of relationships with my teammates.

I help form relationships overtime between teammates by asking them directly to rely on others for information, code review, and discussion of platform improvements, and training.

I've never worked within an organization remotely on its payroll.

I think a defining quality of what makes my organization work well remotely is that we're all independent freelancers, so I don't have to worry about what motivates my teammates as much, because it's fairly obvious, they are working for themselves and are motivated to make money by billing hours.

It seems counter-intuitive, but for over 3 years now I've watched roughly the same group of people, with the addition of new people, continue to work together without drama or politics.

If what's meant here is that it would be hard to run this on a container platform because of the ephemeral nature of containers, assumably you would be using persistent volumes to keep your state safe across the container lifecycle.

That being said if you really wanted to use sqlite for the database, you'd do the exact same thing, use a persistent volume.