One of the junior developers I’m mentoring is applying for their first iOS developer job (if you’re looking for devs in NYC and are open to junior folks, hit me up!) and after an initial interview at this one place, they got a take-home coding challenge. Nice! I like these types of challenges quite a lot – it’s how Artsy interviewed me four years ago, actually.
Artsy is reviewing its engineering hiring practices and I’m reminded of the take-home challenge I got when I interviewed 4 years ago:— Ash Furrow (or is it?) (it is.) (@ashfurrow) March 29, 2018
“Here’s an ObjC class we want to open source. Create a repo, basic tests, CI, and a good readme.”
It’s still up: https://t.co/bsQKgAXSoO
Take-home challenges are better than evaluating coding skills during an interview because they more accurately reflect the environment a coder will be working in. In my opinion, the only valid in-person coding challenges are ones where the interviewer pairs with the candidate and they work together. But I digress.
The developer I’m mentoring got one of these challenges and it was about as good a challenge as you could get. It had:
- Clear instructions.
- A scaffold of empty function bodies where to put code.
- A suite of unit tests to verify your code is correct.
- A Makefile to set up dependencies and run tests.
Coding interviews should reflect the day-to-day work you’ll actually be doing (see: https://t.co/m90S1TR1yS ). In hindsight, “open source this code” was a really apt test for my role here.— Ash Furrow (or is it?) (it is.) (@ashfurrow) March 29, 2018
The barriers between programming languages, between app frameworks, and between developer communities – they are all artificial. All of them. Any two given programmers, no matter their backgrounds, have far more in common than they have differences.
We need to see all developers as peers. To learn from one another. And to celebrate what makes programmers different instead of using those differences to divide us.