Hi everyone! In this article, I’m going to touch on the theme of how to get a job. I want to share with you some of the experience I’ve gained along the way as a programmer. This might be useful even if you’re not a developer, as the ideas I will share are really common for many spheres.
So, you’ve got your CV ready, and somewhere on your LinkedIn profile there’s 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, I’m 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?
I’m not afraid to admit that I’ve 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 I’m sure that there’s value in what I’m talking about here because it’s a tried and tested strategy!
Alright! I can’t wait to share all that I know on this, so let’s get on with it.
Read the Task Several Times
You should do this every single time, even if the task looks simple. It’s possible that the task includes some pitfall or hidden information that you might miss, even after a second read. While you’re reading it through, you’ll probably be thinking about implementation already. Don’t get ahead of yourself, though - you’ll 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 you’ll 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 won’t 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 didn’t 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 you’re hoping to work for by reading public sources. You’ll 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.
That’s why it’s 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, they’ll just exclaim, “This is it!”
Let’s 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, you’d be better off using brand new technologies. This shows that you’re open to using any modern approaches and that you’re adaptable to change, so that they will feel that you’re on the same wavelength as them.
Code Balance
Let’s move on to some advice that is a bit more specialist and focused on programming. Let me share some code examples to show what I’m talking about.
University Programming
This is the amateur style of programming that everybody uses when they’re just starting to learn programming. It’s 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 they’re 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.round
end
This code is a straightforward approach to trying to calculate an order summary. It doesn’t 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 let’s 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)
end
def calc_products_total(order)
order.products.each_with_object(0){|sum, p| sum += p.quantity * p.price }
end
def calc_shipment_total(sum, order)
return sum if sum >= FREE_SHIPMENT_ORDER_TOTAL
order.shipments.each_with_object(sum){|sum, s| s += s.price }
end
def 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_value
end
def normalize_order_total(sum)
sum.round
end
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 let’s 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.
It’s 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 don’t go overkill on this. Too much use of olympiad programming code might make the employer think that you’ll 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, it’s just not possible for test projects to include any olympiad programming, due to the nature of the task. If that’s 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 it’s not beyond your capabilities! I would recommend that you follow the same logic when you’re 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! Don’t 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. Don’t 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. You’re saying to them, “Hey! I’m the guy you’re looking for!” This part of the project is very important, so don’t 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 it’s 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 it’s worth mentioning because it’s so important. The code you write shows the level of your skill, and if you don’t 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 they’re 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 you’re 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 it’s 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. Don’t 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. Here’s 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 can’t remember a single time when I didn’t update some of the steps after that very last check.
I always include a list of the tech stack I’ve used. This helps to highlight some of the better solutions in the project, as I don’t 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 I’ve used. Don’t be shy - there’s 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 I’m afraid. You could follow all the advice above, and still not get the job if there’s someone else even better than you. But there’s always an opportunity for learning.
This might not work in every scenario, but don’t be afraid to try something new. When I’m doing a new test project, I often use it as an opportunity to try out different things that I’ve 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 I’m 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, you’ll 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 you’ll have no regrets about the project you created. See it as an opportunity for growth, and success will follow! Good luck!
PS: Many thanks for illustrations to my friends from Pixel Point
Top comments (1)
Awesome insight. Thanks!