We have all seen job ads with almost impossible expectations. Most of the time, senior programmers set these expectations. So what are they trying to find?

Purple Ponies

• Expert in Java backend (Spring / JEE), Elastic Search (replication, partitioning), Terrform (AWS)
• Expert Python programmer, C/C++ expert, and Unix system expert
• Expert in Java, Ruby, SQL (PostgreSQL), Elastic Search, and Data warehousing

Those are three real recent examples. Each of those profiles calls for individuals with very specific bios and between 16-20 years of experience if the expectations of expertise are taken seriously. Sure, people like that exist, but they are tough to find and almost impossible to replace when they leave. That's why a former colleague called them "Purple Ponies"!

Skill Shape Models T Π M 🐙

The T-shaped skills model is common in recruitment. The idea is most individuals grow along the vertical line of the 'T' as their specialization. Along the way, some pick additional skills forming the horizontal line. Still fewer manage to build two specializations leading to the Π (mathematical Pi) model or even three leading to the M-shaped skill model. Purple ponies probably have an Octopus-shaped skill model 🙂.

Skills Half Story

Why do fewer people pick up multiple specializations? The answer lies in their competency rather than just their skills. They have become competent from a combination of skills and discipline. By discipline, I mean attitudes and practices that make them successful irrespective of the specialization. For example, listening intently, writing well, speaking well, documenting, experimenting, responding to feedback, etc.

Programmers are often hired based on their skills, such as -

• Solving complex problems involving data structures and algorithms.
• Showing how a particular language feature, such as generics, is written.
• Explaining design patterns such as Factory, Abstract Factory, Singleton, Builder, etc.
• Knowledge of a framework's operations, such as Bean initialization sequence in Spring or object lifecycles.

Checking for skills is essential, but after being hired, they will be evaluated on their ability to write maintainable, secure code with good test coverage and meet performance criteria. Therefore, these abilities must be assessed at the hiring time.

Hiring for Skills and Discipline

Here's how to check for common disciplinary characteristics in addition to programming skills.

Testing

Ask them for unit tests to ensure their programming tasks meet functional needs. Check if they can use stubs and mocks appropriately. If you ask for estimates on a programming task, are they willing to give you two estimates - one with and one without unit tests? It's a trick question!

Maintainability

For maintainability, I suggest checking for their understanding of the SOLID principles, the Law of Demeter (LoD), and the ability to apply the correct patterns given different situations. Some examples are as follows.

• If you asked them to review code with big classes with multiple methods, could they break up the class based on its various responsibilities?
• Suppose a method directly initialized an object or opened IO to perform computations. Did they refactor the method to have the object or IO reader/stream passed as arguments into the method?
• Is static code analysis part of their development methodology? What have they learned from the code analysis? For example, I learned to use guard clauses more effectively, have smaller methods, and reduce the complexity.
• Are they able to write or refactor code to use correct patterns? Can they apply patterns such as separating query from command, replacing a large constructor with a builder, avoiding using boolean flags to control method behavior, replacing large conditional blocks with switch-clauses, and so on?

Performance

Since performance is closer to the metal, questions tend to be specialized. However, some common considerations are as follows.

• Basic knowledge of statistics such as average, standard deviation, median, and percentile.
• Constant, linear, and exponential running time as a function of input length (algorithmic complexity).
• Generators, iterators, and other techniques to avoid large memory allocations.
• Appropriate resource cleaning mechanisms such as Python's with, C# using, Java's try(), Ruby blocks, etc.
• Primary considerations of databases such as indexes, read/write replicas, etc.

Security

Security is a vast field, so the questions must start from the specialization. For an application programmer, that would mean understanding the top 10 OWASP vulnerabilities and how to prevent them. For example, do they know how to avoid injection attacks such as XSS or SQL injection? Their answers should not be limited to using a framework to prevent these issues but how to fundamentally avoid them.

You should check if they have exposure to static code analysis (for security) and dynamic analysis (DAST). What mistakes did they learn to avoid?

Next, they should know something about infrastructure security since they may be able to spin up new environments in the cloud with security issues ripe for hacking.

Practices

Your emphasis on the practices might be proportional to their maturity in your organization, or you may hire people to improve the process maturity. Some common ones to consider -

• Continuous Integration - how are the Team efforts integrated towards a build for further stages in the pipeline?

• Continuous Testing - what are the different automated tests that are executed? At what point does exploratory testing occur?

• Continuous Deployment / Delivery - can they explain which one is used in their Team and why it is a good fit for their business or argue against it if they have a different opinion?

• Documentation - how are APIs documented? Are they aware of Open API / Swagger specs? How are decisions documented? How is Architecture documented?

• Observability - how do they try to know of likely issues before customers report them?

• Reporting - how do they regularly report their outcomes to Senior management?

• Product Understanding - did they understand the personas and their needs in their product?

Closing Thoughts

• Remember that what you need to hire is what you need to train. The aspects above also make for a fabulous training program. Over time the training program could provide more collateral for interview questions.

• The motivation for this thought is from Jurgen Appelo's book "Management 3.0," where he wrote about developing competence as a combination of discipline and skills.