A year conducting case study reviews. Facts and some tips.

I'm trying to start blogging, expect some style and grammar errors

One of the things I like the most about my work is that I’m able to perform code reviews, for me this is one of the cornerstones of what being a professional software engineer is, during this part of the software development process is where you have to make all the relevant questions about the code that probably you will have to maintain in the future.

The numbers referenced on this article are just for percentual reference and do not reflect the real number of case studies or applicants.

<?php

echo "Follow the links, I put resources over there to help you";

For our open positions part of the process if that the applicants are required to perform a pretty simple programming task, and is the intended simplicity of the challenge what makes it even harder.

After one year being an active member of the recruiting process, I thought it will be nice to share all the knowledge, cons and pros that I had found so far, I hope this will help you to improve your next case study and who knows, probably join our team.

What happens after someone rings the bell?

Whenever someone completes and submits a new case study we get a very nice notification, from there on we need to review and comment our opinion about the solution and then together as a team we give a final verdict. I’m pretty sure each one of my peers has their own process for conducting the code review, but in the end, it all comes to a boolean response.

My process

For me, its very important to review some things before even going to the code, and to be fair this is where most of the applicants fail.

You might say that the code is what matters but sometimes you need more than good code to make it till the end.

Relevant things we ask for.

1. Provide a guide to run your code, you can assume that your code will be tested on a fresh Linux or macOS installation.
2. You can choose any PHP library or framework.
3. Even when the PHP community follows the proudly found elsewhere pattern, we want to see your code in action and not that you know how to configure a library.

Questions, and answers

• How is the code delivered?
  • 99% of the time the code is delivered as a .zip file.
  • The other 1% the code is not delivered at all.
• Does it follow the applicable FIG patterns?
  • Most of the times they follow PSR-4.
  • Few times they follow PSR-2
• Are they sending the vendor folder?
  • 9/10 applicants did send the vendor folder.
    • Yes, this is a real thing I check, and I'm giving extra points for knowing is not necessary.

<?php

echo "Here I will finally open the code in the editor";

• Are they using a framework?
  • 8/10 used Laravel
  • 1/10 used Symfony
  • 1/10 used vanilla PHP
• If they are using a framework, are they following the best practices?
  • For Laravel, they almost never follow the best practices.
  • For Symfony, the best practices were somehow used.
  • For PHP the best practices are easily ignored in almost all cases.
• Are they providing tests?
  • 1/10 Provided relevant unit tests
  • 8/10 Provided something that looked like tests.
  • 1/10 Had no clue about testing.
• Are instructions to run the code provided?
  • This is good, we always get instructions on how to run the code.
• Is a docker container provided?
  • No, 10/10 times is not provided.
• Does the code perform the requested task?
  • Yes, sometimes it fails but we can figure it out.

Takeaways and tips

1. Give a glimpse at the provided links.
2. If you're gonna use Laravel, invest on having a Laracast account.
3. If you're gonna use Symfony, read the docs because the docs are amazing.
4. Learn how to test your code, this is a super relevant skill if you want to work in this industry.
5. Start doing open source contributions.
6. DON'T MAKE YOUR SOLUTION PUBLIC ON ANY PLATFORM, you will be discarded immediately.

If you wanna work with amazing people doing amazing things

Image taken from Unsplash