Stop Hazing Your Potential Hires
As an employer, it’s easy for an organization like Spreedly to complain about the difficulties of the hiring process. Huge investments of time with uncertain results, noisy pipelines of dubiously qualified candidates, lying recruiters, spamming spammers who can’t read, lack of good science around hiring processes and their effectiveness, etc. Isn’t an employer’s life tough?
But it’s all just whining, because you know who has it tough? Candidates applying for jobs have it tough. They have to put their whole work history in front of a total stranger, invest time and money with no guarantee of a favorable outcome, make a series of decisions that will probably affect the rest of their life, do right by existing commitments while trying to impress us, and at the end of the day get a binary “yes/no” judgement of their ability to do what they believe they’re good at doing, all with little to no recourse or appeal. It makes me tired just thinking about it, but that’s the reality of what it means to go looking for a new job.
You're Smart Enough for Elixir
A brief glimpse into Elixir from an object oriented perspective.
Concurrency is complicated so Elixir must be complicated.
Learning functional programming means giving up all my knowledge about object oriented programming.
Why Elixir? I haven’t needed it so far. It’s probably only for really complicated computer science-like stuff that I’m not doing.
If you’re looking at Elixir from the perspective of an object oriented scripting language like Ruby, Python, PHP, or even Perl then you’ve probably read, heard, or made statements like those above. Even if just to yourself.
I’m here to tell you that I’ve been there. I’ve professionally programmed in each of those languages over my career. Now I’m coming to Elixir from a recent background in Ruby. Let me assure you — you got this!
Programming Puzzles Are Not the Answer
A guide to creating fair and effective hiring work samples.
It’s a common topic of discussion amongst technical organizations that the traditional, in-person, conversation-based, interview process for developers is flawed. The conventional process does not measure a candidate’s ability to perform the job in question, does not result in more successful hires, and allows for implicit bias. As a result, many companies use an interview process based on programming puzzles: one-time exercises that test a candidate’s ability to solve a specific, well-known problem.
While this may be a step in the right direction, it’s still a hugely biased and ineffective approach to hiring. In this post I explain how we do hiring at Spreedly and, specifically, how we measure a candidate’s competence using job and company specific work samples.