I went too far - my tech test failure!

If you follow me, you know right now I'm looking for a contract. This typically means a bunch of interviews and tech tests.

This week, I took a technical test and failed. The requirements were simple; Build a tool that mimics the London transport system.

I read through the requirements, picked my language of choice (PHP) and went about building the solution.

To my credit, I set out wanting to prove my technical knowledge and so I built a mini framework. Personally, I've never been good at non-practical tests, but give me something practical, a problem to solve and i'm all aboard!

In total, this took me about 4 hours to build and had a great time building it. I was so proud of myself and I even sent the employer a summary of my work.

Then I got this message

What went wrong?

Hopefully the above feedback is pretty obvious. I went wrong in two areas:

1. I over engineered the solution, to my credit it was because I misread the header "Please don't" and so did literally everything in the list!
2. I didn't include tests.

Misreading the requirements i think is a lesson for anyone in Software. I missed two words and the outcome was completely different.

Not including unit tests was actually a conscious decision and i'm kicking myself for that.

I felt they were looking for technical ability not technical process, in the future I'll treat tests as if this were a real project in a real situation.

So, instead of being angry with myself, I thought I would try to turn this into a positive and thought I would make my solution public and do a write up on Linked In.

My hope is it that it might help people from making the same mistakes, understand my process, give devs the chance to pick my code apart or even just give people a laugh at my failure!

The Solution

https://github.com/JamesMahy/php-test-failure/

You can run it by just checking out from github then if you have docker installed do "docker-compose up -d" or if you're running a webserver, just point it at the app/public directory.

I won't go through every change during my process but if you would like to see how it evolved you can view my commit log here: https://github.com/JamesMahy/php-test-failure/commits/master

Outline

I tried to keep the project as simple as possible, whilst still going over 2 hours (??)

The root directory was used exclusively for git, docker and any non-solution files.

App directory is where our solution is stored.

I weighed up the options of using an existing framework, perhaps Yii, Lumen. Something small.

In the end, I decided building my own solution would better show off my skills and one of my biggest concerns with development communities these days is the way we so easily throw frameworks at solutions.

Getting Dirty

My first approach when I tackle a project like this is usually to get the basic structure in place, I'll develop my over-arching concept before testing the code. Then later write tests to meet the codes assertions.

This isn't best practice but for me it helps visualise the project architecture in my mind.

You can see this approach here: https://github.com/JamesMahy/php-test-failure/commit/6e10272f9cfb8eb9203440ade2e2c0039f9bf299

I get the basic structure in place, before moving on to the UAT of that phase.

Hello World

After a bit of documenting, cleaning up and introducing docker. I got it live and working and tested the code to ensure what i'd made, works!

https://github.com/JamesMahy/php-test-failure/commit/e7ef632c0d48b31fd6e791c85b80fca725f2cd07

Here you can also see the evolution of our Bootstrap.php which presented the most issues from a blind build.

Why not reflection? I thought it was overkill for this project and this type of loading was a much quicker solution whilst still maintaining the spirit of what I was trying to achieve!

Template Engine

Everything is working as expected and we're outputting "hello world!" in the browser.

So next up, we need to abstract our code from our view, this is to protect against certain types of injection attacks and ensures that if someone updates a template - it doesn't bring the platform down with a typo!

https://github.com/JamesMahy/php-test-failure/commit/8aa239a4cad753056e562423a66568855130f8e4

I love how Blade and various other template engines work, so for this I did a very basic version of one of those. Every template consists of a .tpl file and sits in a fixed directory.

The code passes the required file, passes a bunch of arguments in and then they get replaced with the provided values.

Models!

So by this point you can already tell I've over engineered this simple test considerably. Why stop there? Introducing models! ??

Initial build: https://github.com/JamesMahy/php-test-failure/commit/cb226ef07697402e0c37ae637d84ad21fe7bf510

Some tweaks: https://github.com/JamesMahy/php-test-failure/commit/cc60f7db02ce0a0a6952c19d032f7d316f815ca1

I thought to myself, "Hey we have a journey 'entity' and if this were a real world solution we would probably have multiple entities, maybe users, oyster card etc."

I was very aware at this point i'd probably taken it too far so in an effort to keep it simple I implemented a basic storage mechanism using PHP Sessions.

However nothing could qualm my thirst for over engineering this test solution so I added further abstraction thinking that future developers might want to introduce a Database or different type of storage solution!

Finally finished

Finally, having got all the logic in place and tested through this was my result.

In the future, I'll treat a tech test like it was a live project, following a more TDD style approach and ensuring I read the requirements properly first!

I hope you liked reading this ramble and of course I'm open to all comments :)

Bonus: Please don't feel the need to cover every edge case