Technology evolves quickly to fix problems that exist now. If we are lucky, the technology is good enough to fix problems in the future too, ones we haven’t yet encountered, let alone thought of. However, there are few technologies that exist today in full scale as they did 10 years ago.

Technology evolves quickly to fix problems that exist now. If we are lucky, the technology is good enough to fix problems in the future too, ones we haven’t yet encountered, let alone thought of. However, there are few technologies that exist today in full scale as they did 10 years ago. You could argue that many programming languages are still used from over 25 years ago, but never just that one language. Companies now use many programming languages, tools, processes and automation.

Companies spend millions of dollars each year in software licenses and subscriptions to support their businesses. Who is holding the bag to ensure the business gets value from their purchase? Typically, it is the engineer. The engineer who was hired [most likely] for a completely different skillset [most likely] less than 5 years ago. That coding exam you made this engineer take to get hired is no longer relevant to their value, now you must hope that engineer can learn a new skillset.

Decisions decisions…

At this point, we hit a fork in the road with 3 possible paths: The engineer must learn the new skillset at an expert level in a very short amount of time. The business must go back to the software vendor and pay more money for consulting or professional services. The business must hire and onboard a new person that knows the new software tooling and processes.

If one of these items above is not hit out of the park, the business will miss deadlines, have higher costs and, subsequently, lose profits.

Too many companies today focus on coding exams for hiring. Sure, they want to make sure their candidate can do what they say on their resume, But is that one skill the only thing you want them to work on for the next five years? Probably not.

Can you measure learning in an interview?

Instead of basing hiring decisions on individual tasks and skills, we should be measuring a candidate’s ability to learn and grow. The best way we can do that is by having applicants read documentation, then comprehend and apply it. While software vendors, tools and methods come and go, there is one thing that is always there, documentation. Being able to not only read, but understand documentation is the key to implementing software successfully and in a timely manner.

If an engineer can’t understand documentation, they are stuck. You might be into some champagne problems at a company if no one on stack overflow already asked a question you’re stuck on. Did I mention that some documentation really sucks? Like table flip, awful.

If you’re lucky, one obsure person wrote a blog post or mentioned something on a thread after hours of searching for a solution.

If you went to any engineer and asked them what documentation they dislike the most, I bet they would have a very passionate answer for you. This is just unavoidable in engineering today, however, reading and understanding documentation could be a great test for candidates. Make them look at that documentation you dislike, and then listen to them, what value did they add?

What about all those contacts you have from the software vendor, let’s reach out to one of them! Very rarely do software vendor employees understand their own company’s documentation and this problem scales. The bigger the company, the less likely you are to find someone who comprehends the documentation.

Ending note

If we can evaluate candidates based on their ability to comprehend documentation it empowers both the candidate and the employer long term. Instead of an engineer being voluntold to work on a project, they should be able to select projects or products that are interesting to them because they will be able to implement solutions. Additionally, it helps the company long term as well because they can retain talented engineers.