Insights to hiring Full Stack Engineers and how we hire "the mythical engineer".
- Neil Ludwig (Deactivated)
by Steven Tay, Senior Software Development Manager at Trade Ledger™
As the team (in Sydney) set out to hire full-stack engineers into the company, we realised that there wasn’t a common understanding between ourselves as to what full-stack engineers actually means and how to hire a good full-stack engineer. Questions arose around the type of candidates we should be looking for, the appropriate skill-set they should possess, and the corresponding questions to ask during interviews, how to review their candidacy, etc.
This document is an attempt to address those questions and to set out hopefully useful guidelines for hiring full-stack engineers. In doing so, we also hope to set the right expectation within the teams in regards to their own role and skill set as we continue to evolve into more cross-functional squads.
What is full-stack?
Let’s start from the beginning.
In technology development terms, full stack refers to an entire computer system or application from the front end to the back end and the code that connects the two. The back end of a computer system encompasses “behind-the-scenes” technologies such as the database and the operating system. The front end is anything to do with the user interface (UI). Increasingly, with the rise of DevOps and the adoption of cloud deployments, end-to-end systems now include vendor specific cloud technologies covering storage, compute, network, load balancers etc. Note that we’ve have not even touch on security yet!
The problem with having full-stack engineers
The notion of a full-stack engineer unfortunately conjures up an image of a super-engineer. He or she is this mythical developer who is equally skilled in both front-end and back-end languages and can handle DevOps responsibilities with aplomb.
By some definition a software engineer is someone who employs the proper tools/ techniques/ principles to solve software related, engineering problems. There’s an argument to be made that all engineers should be inherently “full-stack” anyway.
While such a definition maybe correct to a degree, it is not helpful in our hiring efforts. It ignores the fact that both front and back-end technologies have evolved over the years, to the point where entire stacks, even industries has sprung up, and where engineers are commonly domiciled within one area of expertise or another.
As a result of which, true full-stack engineers who can confidently build, deploy and run applications front-to-back, all by themselves are actually few and far between, especially when compared to the vast majority of the engineer population. It is thus extremely difficult and we would argue unrealistic to attempt to fill entire squads comprising of only full-stack engineers.
The hiring of a full-stack engineer may also be unhealthy for the individual and detrimental to the proper functioning of the squad in general. A full-stack engineer hired into a squad of otherwise “regular” engineers, may be asked to lead initiatives on multiple fronts and is often seen as the go-to person for almost any issues in development to test to production. This can create key-person dependency risks, and even worse, cause resentment and burnouts for the individual.
The T-shaped/ or π-shaped engineer
So what do we mean by full-stack engineers when we go out into the market to advertise or interview for a full-stack role? We actually mean a T-shaped engineer. A T-shaped engineer is someone who is skilled in one area of focus, typically front-end or back-end, while maintaining broad range of knowledge and basic skills across other domains, e.g. Testing or DevOps. Having T-shaped engineers enables the squad to be effectively cross-functional. Cross-functional squads are known to be more autonomous, innovative and self-organising. All good qualities for an organisation like us wanting to be more agile.
While the “T-shaped” may be more accurate, it is decidedly less sexy of a term. The industry has adopted “Full-stack” so there’s little use in us fighting against the tide. As such we’ll continue to use the term “Full-stack” where we actually mean “T-shaped”.
Our main qualifier to determine initial suitability of a candidate then should be one’s willingness towards learning and picking up new skills beyond his/ her specialised skills. This is a key starting point. We shouldn’t be disqualifying someone who doesn’t necessarily have the full front-to-back-end experience we look for in an ideal candidate. Nor should we disqualify someone with full-stack experience but doesn’t have the depth of knowledge in one specific area. More importantly, we want to look for qualities and skills in a candidate who fits well within a cross-functional team.
Qualities and skills we are looking for
Technical assessments like phone screens, take-home assignments and white-boarding sessions help us to access a candidate’s technical abilities. These should primarily be focused on his/ her core skills. Questions that peek and probe for additional skill-set should be encouraged especially when they are highlighted by the candidate's resume.
During the interviews we look for engineers who can bring something unique and diverse to the team. They should be complementing the strengths of existing members. Avoid looking for clones of ourselves. Each stage of the interviewing process should allow us to see with greater clarity, the value that prospective candidates would bring to the table.
With this understanding in mind, our interview posture should be one that earnestly seek to see the best in what the candidates can offer and helping them to succeed in the interviews rather than making it difficult for them to get through the interview stages.
Beyond the technical skills, there are a number of qualities that we look out for to help distinguish a good engineer and a great one. Here’re 3 key ones.
1. Growth-mindset
We are looking for someone who is keen to grow and pick up new skills. Most people naturally assume that they have a growth-mindset and would readily profess to possess such a mindset when asked. However most people, and if we are honest enough, even ourselves, are often quite resistant to change.
Having a growth-mindset requires one to be ok to be pulled out of one’s comfort zone and be open to frequent changes happening around him/her. This is not easy, especially for the more experienced engineers who understandably, relies on their past experiences and knowledge to get them where they are currently.
We ought to be looking out for tell-tale signs in candidates who either have or don’t have a growth-mindset in them. Good examples of questions to ask would be like, when was the last time they learn something outside their core skills. Or the times where they are closed or open to suggestions that would change the way of doing things.
2. Teamwork and Empathy
Candidates should be able to demonstrate how they’ve worked together with team mates through difficult times and circumstances in order to push things through. Squad members see entire stories and features as a whole and not just their individual tasks. They watch each other’s back and are happy to chip in to help others succeed. They show empathy for other engineers behind the curve and share their knowledge readily. They would be someone who would put their hands up to guide the less experienced engineers and get them up to speed whenever needed.
3. Passionate
Great engineers are passionate about their craft and spend time and effort to keep improving themselves by learning new ways of doing things. These are the people who care deeply about the quality of their work and strive to make a difference in their world. Clues that help identify whether an engineer is passionate or not, are the extra contributions beyond his/ her normal job responsibilities. Examples include running a pet or side project, open-source contributions, championing best practices or process change in their work environment, or even volunteering in community projects that utilised their technical skills effectively, etc.