Using a competency framework for hiring developers

[FutureLearn Blog]

In this post Mal, a ruby developer and manager, discusses the hiring process for developers and shares the developer competencies we use at FutureLearn.

At FutureLearn, we care a lot about who we hire. We’re a rapidly growing team and we want to make sure that we hire the most suitable candidates, and don’t miss out on people who would thrive here. The tech team regularly retrospect on our hiring process and make iterative changes to improve it.

We discovered when hiring ruby developers that we weren’t confident we were all looking for the same things. We all thought we were being fair and objective in our assessments, but were we really? Were the things we were looking for actually relevant to the job? And how was best to explain this to team members who were new to interviewing?

We decided to get around this communication issue by using a very lightweight competency framework. We came up with 5 things that our current team members do, and that we think all new joiners should be able to do too. Then we fleshed them out with some examples to make sure we all understood exactly what was meant.

Calling it a framework makes it sound like the formal and unwieldy, but ours is flexible. We don’t have fixed questions or a scoring grid, and we don’t use these competencies for personal development or performance reviews. Instead, they are guidelines for things that we’ve all agreed are relevant to discuss, so that we can keep conversations on track and avoid unwanted bias creeping into the process.

We think it’s very helpful for potential candidates to understand what we’re looking for them to demonstrate in their covering letters and interviews, so we’re sharing a summary of the competencies we use. We hope this can also help other companies who are hiring developers, who might want to do something similar.

FutureLearn competencies for hiring developers


The following are the competencies that we think about when assessing people who apply to work for FutureLearn as either Ruby or front-end developers. Other roles may not share these competencies.

Competencies are skills that we require a candidate to demonstrate in order for them to be considered suitable for the role. We choose between candidates based on to what degree they demonstrate these competencies, and how that would complement the existing team’s skillset.

Positions may have explicit requirements, such as a minimum number of years of experience or a baseline knowledge of certain technologies. Candidates must meet these requirements to be able to do the job, regardless of if they match the competencies.

In addition to these competencies, we also consider relevant skills and experience to the role; for instance, if someone has worked in education or MOOCs before, or we are specifically looking for someone with good understanding of accessibility, those would be things we would take into account when considering a candidate.

We do not consider any other attributes or qualities when assessing candidates.

Communication skills (written and/or verbal)

• The ability to explain things, discuss problems, and express ideas, in a way that is clear, understandable and non-judgmental, across different mediums as appropriate.

Initiative

• The ability to take steps without being prompted, at a pace appropriate to both their own experience and the experience of colleagues
• The ability to anticipate outcomes and react appropriately to changing situations
• The ability to seek information and clarification from others where needed, before it poses problems

Technical skills

• The ability to demonstrate a degree of technical skill appropriate to the candidate’s prior experience
• The ability to make technical choices and judgements with sound reasoning, taking into account the impact on developers and users, long term maintainability and the requirements of the work
• The ability to deliver high-quality work, appropriate to the candidate’s prior experience, in a way that considers the current requirements of the product, company and team
• The ability to solve problems by breaking them down into manageable parts, while keeping in mind the larger problem

Teamwork skills

• The ability to write code, reach solutions, and share knowledge with other developers on the team, in a collaborative and supportive way
• The ability to work with product managers and the wider product team in a way that is honest and respectful, by checking requirements and reasoning, explaining technical issues and limitations, and reaching agreements
• The ability to consider and understand different perspectives and needs, including those of other developers, product owners, and the various users of our platform

Curiosity

• The ability to express interest in what both the technical team and the wider company are doing, how we are doing it, and why we do it that way
• The ability to investigate things thoroughly and efficiently, and to find the causes of issues rather than treating the symptoms
• The ability to learn new skills, improve existing skills, and seek out knowledge

We use these competencies:

• when planning interviews, to remind us of what we are looking for
• when reviewing a candidate, to remind us of what is relevant information
• when introducing people to hiring, to let them know what to look for
• and when writing job adverts.

We feel these competencies will allow us to hire the most suitable candidates, by keeping us focussed on relevant abilities and by helping mitigate the risk of any conscious or unconscious bias affecting our decisions.

The hiring facilitator is the person who organises and manages screening sessions and decision meetings. Everyone is responsible for making sure the competencies are followed, but the facilitator will remind you of those competencies at the start of meetings and will make sure any discussion stays relevant and within the competency framework.

Specific things we do not consider

• Attending particular universities or academic institutions, or academic grades of any kind. Grades or attending particular schools do not predict an individual’s ability to do productive work in our team. We do not require candidates to have a degree to work with us – many of our current team do not.
• Prior places of employment. Beyond the experience a candidate has gained by working in a particular company or role, we do not care if a candidate has previously worked in certain companies. For instance, ‘this person spoke about their experience working in a fast-growing team’ is relevant; ‘this person worked at Google’ is not.
• Open source contributions or other non-salaried work, such as giving talks or volunteering. Again, beyond the experience gained by doing such work, this is not relevant to whether a candidate can work well with us. We do not require candidates to provide links to open source work or portfolios.
• Knowledge of specific language features or technologies. We do not require candidates to have academic computer science knowledge, or to know specific technologies beyond those mentioned explicitly in the role description. Particularly, candidates do not need to know Ruby, and can do their code exercise with whatever language they are familiar with.
• Friendship. A candidate does not need to be friends with us to be part of our team. Good communication, respect, and mutual support are covered by ‘teamwork’ and ‘communication’ competencies. We do not care if a candidate is friends with existing team members. We invite candidates to lunch because we want to make them feel welcome, not because we want to test how they socialise. This is why it is optional, and why interviewers are not allowed to join in.

• Want to work with us? Check out our current opportunities
• Want to learn more about us? Read about how we make FutureLearn
• Want to improve your skills? Check out the Improve Your Job Prospects Collection

The post Using a competency framework for hiring developers appeared first on FutureLearn.

Continue reading...