Takeaways from two years of code vetting at Codeable

Next month will be two years I am doing code reviews at Codeable, a nice milestone for me! I decided to put together an article to share the most common mistakes we find, together with some advice to level-up your code and get into a prestigious platform like Codeable, or land any other tech job where good code is a must-have.

If you are not familiar with the whole Codeable interview process, it's organized in 6 steps:

  1. Application

  2. Code exercise

  3. Live interview with a live coding test

  4. Online training on the Codeable Academy

  5. 45 days trial period

  6. Final interview with the CEO

And I am personally involved in step 2 (together with a team of other experts, called Codeable Vetting Team) to perform Q&A and peer review on the applicant's exercises and make sure their code meets our Quality Standards.

If you are curious about the whole process, here is a comprehensive guide.

Now that you have an understanding of the Codeable screening process, let's dive into the topic of this post.

The coding exercise

The exercise is usually a WordPress plugin as we specialize in WordPress development or a custom theme for frontend devs - but I'll talk about the plugin as I am in the back-end team.

We give the candidate specs just like a company would do, in a generic and non-technical way. And we expect and excellent, top-notch outcome to honor the Codeable mission: put together the best freelancers work with the best clients in a friendly & professional environment.

Because just like the application page states: "Only 2% of applicants get in so if you're not that good - save yourself some time!" - which is true, but we are much nicer in telling you if you don't pass.

Learning from your coding mistakes

Different code exercises lead to different mistakes, of course. But over time, I noticed a red line of a full set of issues (aka missed opportunities) that many candidates do and can be easily avoided to level-up your code.

1. Unused code - aka be in control of your boilerplate

We see many plugins based on WordPress Boilerplates, especially this one. It is totally fine to use a plugin, as long as it speeds up your dev process and gives consistency to your code - but is not ok to leave unused code and classes in it, or worst, blindly rely on it.

For example, the boilerplate I mentioned has built-in classes to trigger activation/deactivation functions; and those have to be removed if not used. Also, scripts enqueuing is written, but some plugin may want scripts to be enqueued conditionally and not site wide.

Make sure you don’t blindly just rely on boilerplates but actually understand what’s going on under the hood.

Small details, which make the difference!

2. Code consistency

Another parameter that is often underrated by candidates is code consistency. If you start with array() and then move to [], or mix-up tabs and spaces is an orange flag.

The fact that PHP has no indentation error (like Python, for example), does not mean that aspect should not be taken care of.

Same is valid for:

if() {} vs if: endif;

foreach() {} vs foreach: endforeach;

Choose your syntax style and stick to it!

3. Nonce usage in wp_ajax

This is a case-specific mistake, but also a very common one so I am including in this list. If the implementation requires AJAX you must use nonces, is not optional. It is a requirement in WordPress to improve the security of the requests and prevent Cross-Site Request Forgery vulnerabilities. WP_Ajax without a nonce could be secure, based on the action performed, but could is not enough. We want secure code as well!

And WordPress has a full set of built-in functions to create, validate and handle nonces: https://codex.wordpress.org/WordPress_Nonces

4. Data sanitization and escaping

Data handling is another parameter I care about a lot. As developers, we are responsible for the security of the code we deliver, and bad data sanitization can lead to very dangerous bugs.

As a basic rule, we love to see every input sanitized before saving it to the database, whether it comes from a publicly accessible source, or is input by an authenticated user.

WordPress has a series of sanitization functions and is important to use the proper one based on the expected type of data.

On top of this, the data needs to be escaped/secured when printed out. And here is where I see most candidates falling. The fact that the data is "supposed to be" safely stored, does not mean we can print it out unescaped, and WordPress has helper functions to do that as well:

  • esc_url() - eg. <img src="<?php echo esc_url( $image_link ); ?>" />
  • esc_attr() - eg. <ul class="<?php echo esc_attr( $attr ); ?>"> </ul>
  • esc_textarea()

5. Strings, 文字列, and Гудачи

WordPress is translation-ready by default, so your plugin has to be too.

Of course, we don't expect any multilingual feature (unless explicitly required in the exercise scope), but we do expect all the strings to be translatable. And this means to have a text-domain available, and all the strings passed to the proper localization functions:

Instead, we often see "hardcoded" text string in HTML files, and while the outcome is the same, at core level things are completely different.

For example, all the strings handled by the internalization functions are filtrable using gettext filter, while the hardcoded ones bypass it. And of course, being static, are not translatable in the WordPress way.

6. Delivery experience (invest in your readme file!)

Consider that your plugin/theme will end in the customer's hands, and he/she may be a non-technical person so the readme file is very important.

If the plugin has some post-activation operations and they are not automated or hooked to the activation itself (eg. creating pages, adding shortcodes), be sure all this is nicely and clearly explain in the readme file or a backend help page.

We are not only delivering good code, we are delivering a great experience!

7. Code organization

While we love to see plugins with a folder structure compliant with the WP best practices, this is not a strict requirement. But at least, the folder structure has to make sense.

A well-organized code is a good indicator of a good working approach and organization, which is very important to keep customers happy.

To meet deadlines, set proper expectations, are all critical aspects of the "good freelancer profile" we look for, so start prooving it from your code organization.

8. Variable naming

Keep in mind you may not be the last developer to put your hands on that codebase. Just using meaningful variable names can be a big help for a new dev to understand that code, on top of good code comments.

Of course, the list would be much longer. But I think this selection is representative of the most common ones, and also should give you an understanding of what we look for when selecting new Codeable Experts to join our big, hyper-selected, and distributed developers pool.

As a final note, I have to add that I am very grateful to be part of the Codeable Vetting Team. It helped me a lot to grow as a coder, and I hope this article may help someone to better prepare to this interview or any other coding test.

Thanks for reading.