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.

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.

There was just one problem: the developer was interviewing for an iOS developer role, but the coding challenge offered a choice only between Ruby and JavaScript.

At first, I was a really surprised. Indignant, even. But I took a look, and the challenge was really focused on language-agnostic concepts. Manipulating data models, codifying business logic, that kind of stuff. Nothing specific to Rails or React at all! I pointed the developer in the direction of Visual Studio Code to use as a text editor and told them that they have my confidence. And indeed, they managed to complete the challenge in no time at all. (They picked JavaScript, by the way, which fits their Swift experience more than Ruby, in my opinion.)

You might be angry that a candidate for an iOS developer role was asked to code in a different language. “Where is the Swift coding challenge?” you might think. And I’d understand those feelings. But developers solve problems, and sometimes those problems cross the barrier between languages and frameworks. I would argue that this is a perfect valid take-home challenge because it reflects a real-world development task, just as giving a Swift coding challenge might be a valid take-home challenge for a JavaScript candidate.

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.