The Take Home Task Paradox

During my long career as software developer specialised in mobile area, I had a lot of interviews. some are great, Some are terrible , Some I was terrible.

But if you told me what part of any interview process that you want to purge and eradicate from earth. I would tell you, And you may agree with me, no it’s not the white boarding algorithms (although I’m not that good at it honestly), It’s the infamous TAKE HOME TASK.

But why man, someone hiring recruiter asks, it’s a good indication of the developer ability to work and code!

Well, here’s my two cents about it from a man who gave and took home tasks through the last couple of years..TLDR; No It Doesn’t. And here is why.

The main issue with the home tasks is that, There’s no specific methodology of what the reviewer will want to see. I see you shouting, my dear reviewer

“Hey that’s not fair .. The only methodology is quality here. We want good structured code that do the job, that you can afford to build in 2 hours.”

Well that what you said, not what I saw people do, Even me myself got caught in that deep inferno layer. We claim that we want quality code. But what we’re actually looking for is a code that match exactly what we daily do and got used to.

Let me give you a few example from my real life, shall we:-

Example 1:

Company: Given a basic app, and our famous SDK, Please implement it according to that documentation.

Me: hmm there must be some trick. This is a 5 minutes task. Let’s see, I can restructure the App a bit. Fix some bugs I can see. Yeah yeah. I’ll use some complicated Design pattern here to show some muscles. Will show off a bit my open source network layer, They will love it indeed. Will fix the design to make it modern. Now will write down a good README.md to make it easy to set up the app. No No, Let’s give them a makefile to set it up automatically.

Result: Thanks for taking the task. But we decided to pass, the code is “Over Engineered and you had re-invited the wheel by adding new network layer.”

Me: !!!!

Ok Next Time I’ll give some basics and just follow the task document.

Example 2:

Company: Please build some app, don’t care of design, just grab some data from this URL, put it in list. and show us.

Me: Ok , I promise I’ll just make it MVC pattern . Nothing more. Straightforward, though my heart is bleeding from this, But whatever the job need.

Result: Thanks for taking the task. But we decided to pass, we see you haven’t use any complicated design pattern and MVC is actually not scaling. we loved your test cases and your documentation but nah. our priority is design pattern here.

Oh For **** sake . Can you tell me that upfront. Ok lesson learned, I’ll ask during the implementation next time.

Example 3:

Me: What design Pattern should I use please :)
Result: Thanks for taking the task. But we decided to pass, You ask so many questions and the task is clear.

Example 4:

Me: just working on the task and making two different apps variant, so they choose from .

Result: Thanks for taking the task. But we decided to pass, you haven’t ask any question

But the most funny one was one that the task was super clear, they even listed the cases that you can build TDD from it directly.

The result was You have a typo in the name of the class “Task1VeiwController” while it’s view not veiw .. That kind of carelessness is unacceptable for our company.

Me: Well for a company that manages to make chicken taste bad, good luck with that (Wink Wink)

The problem from my PoV that you give the developers 2–3 days and tell them that this task should take 2 hours but feel free to give it anytime in the next week. And expect a production ready result, Without setting rules and KPIs. So no matter who reviews the code we get the same result. I had an argument with a colleague once because he insist that 60% test coverage is not enough for such task while it should be 100% . Well, first the developer covered all logics that need to be covered. He doesn’t need to fake test just to satisfy your OCD per se. And if we didn’t write it in stone on the task document that we need 100% , Then it’s up to his judgment.

Some Companies send this task because everyone else does that. I stumbled upon some that they came to the next interview without taking the burden of seeing the code. And a lot of them reject without even discuss the developer decisions.

Then you get accepted in one of these companies someday, And what you see afterwards is that we take our time to build the smallest feature, Making design documents, Grooming, Estimate every little line of code. So why was the hustle you made early? That became just like the white board algorithms. people need to train for it just for interviews, while in reality, well, Nobody cares or use.

Companies need to take the take home task more seriously and feel the pain that the developers gets from such tasks. I’d give the task upfront to the candidates and ask them to estimate every thing in it. and see what he would actually do. Real life problem-solving.

Personally Speaking, I stopped 2 years ago taking any home tasking unless I really like the company’s mojo. Or it’s a bit descriptive and know exactly what it needs.

It’s a paradox as everything in the interviews process of software developer, and we are far away from making it work. But let’s call it a cry in the dark room, maybe it can change the heart of this bastard that refused the task because it’s View not Veiw.