Deadlift: Showing off Your Strengths in a Job Interview Test Project

Hi everyone! In this article, Im going to touch on the theme of how to get a job. I want to share with you some of the experience Ive gained along the way as a programmer. This might be useful even if youre not a developer, as the ideas I will share are really common for many spheres.

So, youve got your CV ready, and somewhere on your LinkedIn profile theres a list of all the companies that you used to work for - this list might be long or short. But potential employers will probably want to check your experience out for themselves too - in fact, 99% of the time this is going to be the case. For most jobs, there will be multiple stages to the selection process, but in this article, Im going to speak about the test project part only. Often, recruiters will set a difficult coding task for applicants, to give them a chance to show off their programming skills.

Why Should You Trust Me?

Im not afraid to admit that Ive had several failed attempts at test projects in the past. After that, I had great feedback for my last five completed test projects, from five different companies. In four cases, I got a job offer as a direct result. So now I understand how to do it right, and I think I can safely say that all my subsequent test projects are likely to be successful as well.

To be honest, I had some doubts myself about whether my ideas would work for less experienced developers. So, just to be totally sure, I ran an experiment (we all know how important it is to test stuff, right?) I introduced all these ideas to a friend of mine, who is a less experienced developer, before she attempted to solve a test question. She followed my advice, and sure enough, she got the job, thanks in a large part to solving a test project. So Im sure that theres value in what Im talking about here because its a tried and tested strategy!

Alright! I cant wait to share all that I know on this, so lets get on with it.

Read the Task Several Times

You should do this every single time, even if the task looks simple. Its possible that the task includes some pitfall or hidden information that you might miss, even after a second read. While youre reading it through, youll probably be thinking about implementation already. Dont get ahead of yourself, though - youll have enough time to work it all out. Taking your time is actually a pretty good rule of thumb for most of the future tasks youll undertake in your dream job.

Wrong Requirements? Make Your Own!

Sometimes while reading the task, you might notice that there are some inaccuracies or even some negligence on the part of the task author. Remember, skewed problems will lead to skewed solutions and you wont be proud to show off such a solution. So feel free to make some modifications and go in the right direction. This might even be part of the test. Of course, you should logically explain your decision and make it clear that you didnt just change it because it was too hard for you to do it as originally requested.

Read the Vacancy Description Again and Research the Company Thoroughly

You can get a lot of information about the company youre hoping to work for by reading public sources. Youll be able to find out what the perfect candidate looks like, what sort of problems they will be solving, and in what particular ways. Very often your test project will be the same sort of thing but in miniature. It means that you should try to make your solution as close as possible to the original one.

Thats why its so important to understand this kind of background information about the company. This knowledge will definitely help you to address some of the questions about base architecture and tech stack picking and makes sure that your answers will be convincing. This way, when your future employer is reviewing your solution, theyll just exclaim, This is it!

Lets take a basic example. If the company you are applying to work for is a huge enterprise, I would recommend that you pick a mainstream stable technologies set, to show you are aware of the importance of using a reliable product. On the other hand, if it's a small startup company, youd be better off using brand new technologies. This shows that youre open to using any modern approaches and that youre adaptable to change, so that they will feel that youre on the same wavelength as them.

Code Balance

Lets move on to some advice that is a bit more specialist and focused on programming. Let me share some code examples to show what Im talking about.

University Programming

This is the amateur style of programming that everybody uses when theyre just starting to learn programming. Its the type of code that is just about good enough to solve the problem, but nothing more. Here is an example on Ruby but I guess everyone will understand what I mean, even if theyre not super familiar with Ruby.

def calc_order_total(order, user)  sum = 0  order.products.each{|p| sum += p.quantity * p.price }  if sum < 2000    order.shipments.each{|s| s += s.price }  end  if user.coupon && order.apply_coupon?    if user.coupon.value >= 0.3 * sum      sum *= 0.7    else      sum -= user.coupon.value    end  end  sum.roundend

This code is a straightforward approach to trying to calculate an order summary. It doesnt follow code style rules, including constants and the ABC metric. We probably all wrote this kind of code when we were trying to solve some programming projects at university. I would suggest that you should never write code like this in your test project. 0% of University programming in your test project

Industrial Programming

We could also call this professional programming. Every solution algorithm that springs to mind will initially look like a university-programmed mess. But every professional programmer will rethink the idea and improve it, using best code practices to deliver high-quality code. So lets briefly try to improve the code of the example above
(FYI I do not pretend that this is the perfect implementation, I just want to show you the way of thinking).

def calc_order_total(order, user)  order_total = calc_products_total(order)  order_total = calc_shipment_total(order_total, order)  order_total = apply_coupon(order_total, user, order)  normalize_order_total(order_total)enddef calc_products_total(order)  order.products.each_with_object(0){|sum, p| sum += p.quantity * p.price }enddef calc_shipment_total(sum, order)   return sum if sum >= FREE_SHIPMENT_ORDER_TOTAL   order.shipments.each_with_object(sum){|sum, s| s += s.price }enddef apply_coupon(sum, user, order)  return sum unless order.apply_coupon? && order.coupon  coupon_value = user.coupon.value  if coupon_value >= COUPON_COVERAGE * sum     return sum * (1 - COUPON_COVERAGE)  end  sum - coupon_valueenddef normalize_order_total(sum)  sum.roundend

Hopefully, you can see that this code is much easier to read and understand. It shows every step of the total order calculation, and you can manage the process by modifying constants, values, and concrete logic parts. Your employer is going to prefer this type of code, as it is much cheaper for businesses to maintain and modify.

One more example of professional programming is the ability to use foreign code components instead of reinventing the wheel. We could have libraries or services available in our system that are already doing all of this, so lets just use them:

def calc_order_total(order, user)  order_total = order.products_total  order_total += CalculateShipmentsTotal.call(total: order_total, shipments: order.shipments)  order_total = ApplyCoupon.call(total: order_total, user: user, order: order)  NormalizeOrderTotal.call(order_total)end

Using this type of code will show your employer how professional and valuable you are as a developer.

Its important to strike a good balance between using existing instruments, configuring them, and writing custom code. This part is important, as it shows how good you are as a developer and demonstrates that you can close off regular tasks. It doesn't matter if the task is simple or complex, big or small. This is probably the most important point, as this type of task will make up 90% of your future work.

Here is the code balance rule: 90% of industrial programming in your test project. What about the remaining 10%?

Olympiad Programming

This kind of code will demonstrate just how smart you are. It should include some indication of your wider skills. This might include a strong mathematical background, skills in performance optimization, or the ability to implement beautiful infrastructure solutions. And so on. But dont go overkill on this. Too much use of olympiad programming code might make the employer think that youll use overly complex methods to solve simple tasks, which is bad for business. So the rule is this: 10% of olympiad programming in your test project.

Sometimes, its just not possible for test projects to include any olympiad programming, due to the nature of the task. If thats the case, you should just write 100% industrial programming code and leave it at that.

The Deadlift Idea

What if the task is too big? Or the task is too small? In weightlifting, you always need to pick the perfect weight to suit your abilities. Bigger is better, but make sure its not beyond your capabilities! I would recommend that you follow the same logic when youre working on the test project. If the task is too big, you can underline the most important elements and implement those with high-quality solutions. If the task looks too simple, you can add some tech magic to show off your professional skills. But be careful! Dont punch above your weight - you should find the right level and ensure that you can pull it off with a nice technique, using the code balance explained above.

Solve the Main Problem

Now you know the list of subtasks you need to solve and you know that you need to research the nuances of the business so that you can easily identify which is the most important part of the test project task. This is the element that you should focus on implementing with the most style. Dont be afraid to rewrite it a couple of times.

This part of the code will definitely be reviewed, and its quality is what will reveal your main characteristics as a developer. Sometimes it will include the 10% of olympiad programming that I mentioned, but not always.

You should be looking to use best practices and classical algorithms in solving these kinds of problems; this will give good results, and make your employers sit up and take notice. Youre saying to them, Hey! Im the guy youre looking for! This part of the project is very important, so dont be afraid of skipping some low-priority elements in order to spend more time on this.

Keep Commits in Good Shape

Your git history shows your thought process. Inconsistent naming and code changes in your commits reflect a mess in your head. So you should be ready to put a lot of work into your git history. I would say at least 30% of the time you have available for the project should be spent on beautiful code changes in your git history. First commits are about infrastructure changes, project init, and adding in some of the most basic stuff. Then, as you get deeper into solving the problem and move from simple to hard, each commit shows each step you have taken.

Apart from anything else, your git commits prove its your own work. Something to consider is that a long commits list shows your motivation to work in the company - for some employers, this is really important and will help you to stand you out amongst the other candidates.

You should use conversions like this https://www.conventionalcommits.org/en/v1.0.0/ or this https://seesparkbox.com/foundry/semantic_commit_messages to keep consistent commits messages style.

Use Code Linters

Write clean, readable, scalable, maintainable, secure code. This is obvious advice, but its worth mentioning because its so important. The code you write shows the level of your skill, and if you dont demonstrate the required level to meet the requirements of the job, then you may not pass the test. Use code linters to help you avoid any sloppy moments in your code. This will improve the overall impression that you make on the employer when theyre reviewing your test.

Write Tests

Writing tests is important. The way you cover your code with tests shows how professional you are. Enterprise project developers usually spend more time writing tests than writing actual code. So imagine that youre already working on the enterprise. Cover everything you know how to cover in the right way. I would even recommend using the TDD approach. Actually, I think you should do this anyway, even if its not specifically required or requested in the task.

Selectively Fix Bugs

The main usage scenario should 100% work. This is actually good advice for QA specialists as well: do test the positive flow. Dont waste time on fixing tricky bugs and edge effects. You definitely have more important stuff to work on. P.S. Got issues with bugs? Read my previous article ;)

Readme Is Important

When you deliver your test project solution, you should be 100% sure that the inspecting person will see the results and will appreciate them. Well-composed Readme is a key factor in achieving this. Heres a list of things I usually include in the Readme file:
Step-by-step instructions on how to start the project and see the results. I always assume that the checking person is not a programmer at all, so my steps are quite detailed and accurate. Anyone should just be able to blindly follow the steps and get results. After I finish the project, I test all these steps one more time to make sure that they still work. This is good advice to follow, as I cant remember a single time when I didnt update some of the steps after that very last check.
I always include a list of the tech stack Ive used. This helps to highlight some of the better solutions in the project, as I dont believe that every line of code will be read. So this helps to prevent the scope of the project from being underestimated.
I might mention some of the best ideas and tactics Ive used. Dont be shy - theres no harm in giving yourself a bit of good PR. I also explain any non-transparent solutions, especially if I had any reason to change the test project conditions. Once again, I am pretty much sure nobody will read ALL your code, so when you explain some of these things, it gives a better understanding and helps the reviewer to appreciate the best elements of the code.

Last Words Before You Go

There are no cast-iron guarantees here Im afraid. You could follow all the advice above, and still not get the job if theres someone else even better than you. But theres always an opportunity for learning.

This might not work in every scenario, but dont be afraid to try something new. When Im doing a new test project, I often use it as an opportunity to try out different things that Ive always wanted to do but never had the time before.

I use modern code style approaches that are popular in the tech stack. I make sure Im familiar with all the latest versions of the programming language and all libs, frameworks and technologies. I use the latest features and read changelogs looking for new stuff to play with and try new ways of solving known issues. That's how I discover new things. And it helps to keep me interested in my work too.

If you do everything as perfectly as possible, youll fall in love with your project. Even if nobody notices it and nobody calls you back, you know that you can be proud of it anyway. Shit happens, but youll have no regrets about the project you created. See it as an opportunity for growth, and success will follow! Good luck!