When looking for potential DevOps candidates coding tests are not at all uncommon. Unfortunately many of them are remnants of older computer science class tests. I'd like to go over some of the points on why it may not be getting the best DevOps candidates.
Vertical and Horizontal Scaling
The traditional Big-O notation type algorithm theory tends to be more oriented towards vertical scaling patterns. Such optimizations are an attempt to squeeze as much as possible out of conventional hardware and reduce the need to add CPU, memory, etc. In modern DevOps based on a micro-services architecture you really don't see this as much.
This is because horizontal scaling is utilized and code tends to be compartmentalized into functions as a service or container units. Less code is applied to make services work. Performance optimization now deviates more towards how various services connect. Network flow in particular suddenly becomes an important factor in the performance of applications.
Managed Services
If you're using AWS in particular, there are a lot of services available to handle anything from the most basic to the most complex tasks. I wouldn't implement a queue system in my code as I'd just use AWS SQS instead. Crunching big data can be done through various service such as RedShift and Athena. As a DevOps engineer I won't be thinking about which binary tree to use but instead which service might meet my needs.
Higher Level Languages
Python and Ruby are some examples of very easy to work with languages. Modern languages abstract out a lot of the low level algorithmic work. This is essential in a modern business environment where customers aren't going to wait for a bubble sort implementation. Even if such algorithms were needed there are plenty of language packages and standard library solutions to handle it quickly. This means having such algorithms in the back of our heads isn't efficient use of time versus knowledge of python generators.
Performance Monitoring Tactics
How we deal with performance in a cloud based tooling era deals more with call patterns and inter-service latency. Even if a performance issue is found in the code the solution is very unlikely to be addressed by a low level algorithm. Instead it would be a language feature such as generators or refactoring object instantiation. DevOps engineers aren't thinking of this in terms of Big-O notation nor is there really a need to.
So What Should Be Tested?
Instead of testing for computer science courses, instead tests against the role. Programmatic questions should be related to how the role in question uses the appropriate programming language. I've personally done this by showing a somewhat stripped version of project code and having the candidate walk through it. If it doesn't work out I even go so far as to let them know what concepts to study up on.
It's also important to not forget about the actual infrastructure itself. Asking about Terraform or other IaC solutions is very crucial. It's also important to ask about the cloud architecture in the event it's a 100% required skill. Questions should be adjusted based on the amount of experience you expect.
Conclusion
I hope this was insightful on how programming tests in DevOps interviews should be handled. Again, it's important that what you're testing matches the role itself. Otherwise you'll get people really good at computer science tests and may be filtering out amazing candidates for the role.
Top comments (0)