So you wanna hire a developer — why are you interviewing for a mind reader?

5-minute read

Recently I was approached by a tech services company who where interested in hiring me, only to immediatly send me over to a customer of theirs. I would had to pass both a full interview process with the both the tech company and the customer. I would had to implement a sample app as of the customers choosing. The task that I got was this:

The assignment:

Create an app that is capable of visualizing the attached csv file on the screen. parse it on a background thread

plus a csv file with 3 rows of non-sensical data.

As this assignment was very unspecific, I decided to use an architecture that I am writing a book about. An architecture that is my response to the crisis of agile that I witnessed in so many team. How would one expect to be agile — meaning able to react to change fast — when their feet are stuck in spaghetti code while they play mikado?

This architecture is developed specifically to support agility, by

  • using the highest possible degree of decoupling
  • truly handling UI as an I/O device
  • using uni-directional flow throughout the app
  • splitting the codes into features and use cases (as in Uncle Bobs Clean Architecture), easily presentable in agile processes
  • Allowing for easy TDD and BDD
  • supporting domain specific messages, at compile time

I thought by using this architecture I would be able to collect feedback for my book, even if I wouldnt end up getting the job. And while the tech companies reaction was quite enthusiastic (they compared my codes to some of their architectural research), the customers reactions werent. They actually were rather insulting:

There were some positive aspects identified, but also negative ones which weighted more. Some of issues:

  • Principles of good OOD and OOP not followed.
  • The presented architecture in various aspects is far from acceptable in general.
  • Unit tests do not meet general quality standards.
  • Insufficient understanding of the Swift language.
  • Insufficient care about code style.
  • Not a good strategy by offering unproven own technology without documentation.

Dear Reviewer,

I have some followup questions on that. And you know: I prepared my code during several evenings. You could had at least honor that by giving me proper feedback — not some 1-line ramblings.

  • Principles of good OOD and OOP not followed.

Well, the best known explanantion on what OOP is comes from Alan Kay and states that it is all about message sending. If you inspect my code, you would find that this is exactly how my Features and UseCases do communicate. You expected me to do more crazy sub-classing? Without diving into it: There are great arguments on why inheritance might be harmful. Just google it. ie. Go is considered to be a pretty good OOP language — without any subclassing capabilities.

  • The presented architecture in various aspects is far from acceptable in general.

And that is why? See above what unique features it got. But if you want to have a buzz word: my architecture is explicit reactive.

  • Unit tests do not meet general quality standards.

The git history would show you, that the code was actually developed in TDD — I wrote the tests before I wrote the logic code. How can that be unacceptable?

  • Insufficient understanding of the Swift language.

So I missed to use your favourite Swift feature. What was it? Generics? I simply didn’t need them. Classes? well, I refer again to the inheritance discussion.

  • Insufficient care about code style.

When you looked on how I layout the code, didn’t you think that there is reason for it? As you didn’t care to ask, here is my answer:

It is my very own personal opinion that there is no benefit layouting code after strong rules. The compiler doesnt care. And infact a programming language isnt a computer language. It is a language for humans to use. So it is my very strong believe that we must format our code in a way that it is beneficial for the human in front of it.

An example, taken from another blog post, but this time with syntax highlighting from Xcode, as it makes things even clearer:

Example 1, as seen in the blog post:

example 1

Example 2, some conventions might force this:

example 2

Example 3, other conventions would want this:

example 3

I would argue that the first example is the best code for the developer to grasp. It shows clearly which bits stay the same and which change, while especially in example 3 you have to scan it line by line. Code typography would had been a topic I would had love to discuss with you, instead you wanted me to guess your favorite formatting.

  • Not a good strategy by offering unproven own technology without documentation.

This is the best one: So you want to hire experienced developers, but you consider showing something unique or novel to be bad. Also I included a readme pointing out the philosophy, features and benefits of my code. And the code is easy enough to understand — if you are willing to do so.

Dear Reviewer,

I think, your motivation during your reviewing of my code was not to find a good developer, but the desire of fullfilling your confirmation bias. You didn’t strive to make your team more resilient by adding to it’s diversity of ideas, but to copy a certain ideal you assume of a good programmer. Possible yourself. But as Kevlin Henney and others have shown: you cannot speed teams up by just replicating the same developer experience over and over again. You must support a versatile team, not only in terms of gender and skin color, but also different ways of thinking.

Or in other words: You should look for maverics, not mind readers.

Discussion

Please feel free to discuss this article.