On iOS interview exercises

Today I saw this Tweet:

If you're hiring an iOS developer, please, for the love of god, don't do "fetch this API and show a table view with results" task.

— Michał Kałużny (@justMaku) July 24, 2017

It spawned a great discussion on Twitter and thought I'd share my perspective on this.

Although this may seem like a dull exercise to ask an interviewee to do, in my experience I've found it to provide a great amount of insight into how the one doing it thinks about solving a problem.

By revieweing this exercise's deliverable, I can know...

• How they think about data modeling
  • Are the models structs or classes?
• How they reason about data flow
  • Did they create a manager for the data layer?
  • Whose responsability is to download the data and parse it?
  • How should changes be bubbled up to the UI?
• How they feel about using dependencies
  • Did they use Alamofire to consume the API?
  • Did they use a library to parse JSON?
• How they approach API design
  • Are closures used intellengtly, or at all, where they would become handy?
  • What's the "no-data" state, nil or []?

I could go on.

What's best, is that many interesting conversations that provide even more useful information can be spun-off from any of those questions above.

In my experience, I've found this very exercise to have a different outcome every time I use it to interview someone.