To assess a developer, it is not enough to say that the person must be 'strong', 'responsible' or 'experienced'. Competencies must describe observable behavior that matters for the role.
Start with the work
Define what the developer actually does: writes code, reviews pull requests, designs architecture, communicates with product, estimates tasks, mentors juniors, works with legacy code or solves incidents. Competencies should come from this work.
Technical skills and behavioral competencies should be separated but connected. For example, system thinking may appear through architecture decisions, debugging logic and ability to explain trade-offs.
Make competencies observable
A competency should answer the question: what does a person do when they demonstrate it? 'Communication' may mean clarifying requirements, explaining technical risks, asking questions early and documenting decisions.
Use behavioral indicators for different levels. A junior developer follows standards; a middle developer applies them independently; a senior developer creates and improves them.
Assessment tools
Use a combination of interview, technical task, case discussion, code review, work history and feedback from colleagues. No single tool is enough.
A good competency model helps not only hire developers, but also give feedback, plan growth and discuss expectations with the team.
This English version is translated and edited by meaning. Obvious spelling and recognition errors in the Russian source are corrected in the English wording.
Open Russian original