Lessons Learned from a ‘take home’ assignment gone wrong

Applying for Software Engineering Jobs has really become very strange. I have now been working in the industry for over 15+ years. During this time it seems that hiring has really become broken. Let’s see how I failed this next interview.

The Process

This time around, a recruiter contacted me directly. I had a pleasant 30min chat with the recruiter and was then given a 6h take home assignment to complete and would then be invited to a 1hour technical discussion interview and then after that a 1hour interview with HR - and then they would present me an offer.

I agreed on doing the challenge under the condition that i can publish my result on my blog. Unfortunately I did not get that in writing - and the recruiter then ‘forgot’ our arrangement. I removed all original questions and code references from this article.

The Assignment

Overall a small Admin interface and a view for users should be created. I was given access to a git repo. In the repo i found a working backend in Java or NodeJS server with SQLite DB and working REST-API with Swagger Documentation was provided. In the Readme four very vaguely defined tasks

Task analysis

1. It should look pretty

That the program should be aesthetically pleasing is not the core skill of a developer - it is a core skill of a designer. Even a designer would reject this task as it is too vague and undefined. In a professional setting this would mean creating several different drafts and then reevaluating with the client what style he prefers.

I would assume the company provides their own corporate style-guide you should follow and when working at the company it is more clear on which direction the UI design should be. However for an external person just joining this is not clear.

This is not really a task that a developer should solve. But in the end the biggest problem with this task is that it cannot be evaluated objectively.

2. It should be easy to use

Again a very vague requirement. If you do not know who your target audience is you cannot make it ‘easy to use’.

A CommandLine tool may be very easy to use for some users, but adding a GUI may have the benefit that more people can visually comprehend it - equally being easy to use.

Equally there is no mention if it should be used on mobile or web or command-line. Again I have to wonder how will this task be objectively evaluated?

3. Create an Admin Interface

Now we are getting somewhere. Here there is also a little more information: It should contain 2 views, one for assets and one for users.

Sadly in the descriptions functions you would expect from an admin interface are missing. For example ‘delete all assets’ was described, however the api only allowed to delete a single asset at a time (and it probably would make sense to add a delete single asset functionality to the UI.

This task at least can be evaluated objectively. Either the functionality is there or not.

4. Write High Quality Code and add Tests

Again this is meaningless without specific metrics. How is High Quality Code defined? How should the code be optimised? Most pieces of code can be optimised either for memory usage or cpu usage. Which one should you focus on?

Similarly you might want to optimise your code for readability and maintainability but sacrifice memory efficiency. There are always tradeoffs that you are going to make.

Without any clear metric how this task is objectively evaluated. There was not even a hint on how high the code coverage is suppose to be.

Feedback

I completed the challenged after 6 hours. Implemented all functions and a couple of additional helper functions and had a unit test code coverage of around 90%. I used Typescript with React functional components with hooks.

Recruiter: The quality of your solution is significantly lower than that of the other candidates. Is this really the way how you coded at your last company?

Me: I worked around 6 hours on this, just as you requested

Recruiter: Oh, yes thats the minimum - we expect you to be passionate about programming and spend at least 12-18hours on this task.

They then also reversed their decision that I am allowed to publish the question on my blog. They then continued to basically claim ownership over my code, despite that I never signed a NDA.

Of course this immediately erodes any trust in the company. If you are not allowed to publish the solution you can assume a the company wants to claim ownership for your code and use the result of the coding challenge in their own product. - There was probably never a real job, they just used you to provide them with free labor.

Lessons Learned

The next time I will be very careful If i really would want to spend my time doing a take home assignment. I have enough professional experience that should be enough for a company to make an informed decision if they want to hire me or not.

Just imagine using this kind of interview process for any other profession, “oh first show me that you know fix my broken toilet - then i will decide if I will hire you as a plumber”

• If the task is so broadly formulated that you can do whatever, you only can fail the task
• Get all additional agreements with the recruiter in writing
• Don’t work for free for companies