A few days ago I was thinking about the hiring processes for developers. I had opportunities to participate actively in the selection processes in some companies and of course, I’ve been interviewed many times.
On both sides of the same coin, I found it pretty difficult to define what a good company for me as a developer is, and what a good developer means for the few companies where I select some candidates.
When as a part of a product team you look for a new developer, I think it’s very important to define and specify technically and culturally in a clear way what is expected from the ideal candidate, additionally from the organization’s perspective but I would like to focus on from the development team perspective. Sounds obvious, huh? sadly it is not in some cases.
Write an internal document within the development team with those specifications to think about and iterate over it and expose those things that sound very obvious but if you take a closer look, sometimes it is not. It will give a good idea about the dev team’s identity.
I also, saw managers selecting, or defining developer positions and selection processes, or indeed members of others teams -unrelated directly like Marketing, Management, Sales, etc- taking the decision if the candidate is or isn’t a good developer.
Any other team must be more aware of what is needed from a developer that the development team. It is for that reason it’s so important development team achieves enough maturity to choose their own colleagues and ask for it and therefore be responsible for it. Of course recommendations, suggestions, and concerns from other teams must be an important input I think.
As a starting point, it is very important to define what a “good developer” for your current product team means in a clear and detailed way. If the team is totally aware and agrees about what technical and non-technical aspects they are looking for in a candidate, you should be able to answer very quickly “How do we know after the interview if the candidate is a good developer for us?”.
Of course, each team needs different developers, with different experiences, etc. But from my perspective, there are points in common that for me are totally independent of almost every startup or small/medium tech company. I will try to define, as a first approach what a good developer is for me. I think it is someone who:
- Has 3 main characteristics: Passion, talent and potential:
- Passion: you want to see the enthusiasm when explaining or talking about development, and explaining how it impacts customers. He talks with passion about how important working for clients is. He loves his profession and knows a job is not just a job. He looks for a productive partnership where they can learn and wake up happy every morning before work.
- Talent: A talented developer has a good foundation in software development: clear and clean code, with good practices, CI/CD processes incorporated, TDD, design thinking, refactoring, etc.
- Potential: Good developers want to learn more and expand their knowledge. They learn quickly and they know that they do not know everything, so they love learning from others.
- Is open to changes: a good developer does not work with the same technologies for many years; they work in Agile teams and expand their broader constantly. They have had to adapt to new environments, technologies, projects and business models. In other words, they have at least a few years of experience embracing changes.
- Is a fast learner.
- Takes the time to try new things.
- Loves to share their knowledge and learn from others.
- Is (or is willing to) be part of some developer community.
I see so frequently job descriptions looking for specific tech stacks, all exposed in a long items list with different levels of details. For example:
– PHP 7.1 / Laravel
– Jenkins
– React.js
– UI/UX
What does that mean? Does someone with 10 years of experience in PHP 5.6 or Symfony qualify? UI/UX? that’s not a technology. There are multiple specification levels in the same list and if you are a developer, you know that does not make sense.
Frameworks, and tools are secondary and should be exposed only to inform the candidates what technologies you use, but not required. Talented developers can learn and use any technology pretty quickly. They are not specialists in tools or languages. A good developer is not worried about technologies because they know those change quickly.
They work in agile environments where everything changes quickly, the stakeholder’s opinions, the user perspective, the product owner’s ideas, the client’s request, the design, the architecture and of course the technologies.
Good developers do not spend several years in a fixed stack tech, because they love learning new things, and enjoy experimenting and practicing new languages, new tools and new products.
Instead of a big fixed tech stack as a requirement, I think a good job description should keep the focus on practices, and processes and mainly a good description of how the developers contribute to the product within the product team environment.
On the other side, I think good developers are aware and have a clear idea about what a good company means to them. This, just like the previous assumption, is susceptible to the circumstances. Sometimes a developer wants to earn more money because he needs to pay the university for instance, or because a new family member will be part of the current one. Sometimes the developer is willing to learn new techniques to expand his knowledge, or be part of a smaller/bigger team, etc.
In any case, a good developer knows that a new job is a new partnership with his employer. It means, there will be a strong and long-term relationship with the product and its users. There is not any boss/employee relation (behind the legal terms). The product, the vision, the medium / long term goals, the culture and values are very important in terms of the partnership.
What good developers are looking for?
If you are working in a company, you know that you need to attract good developers and there is a huge demand for them so if you want them to join your team, you need to consider that they are very selective about who will be their future employers, their working environment, autonomy, mastery, purpose, and the partnership style they will establish. They want to know how the team works and if there are talented and passionate people in place. You need to be aware that good developers are not the only ones being interviewed, they are also interviewing companies and they will exercise their option to reject the bad ones. The way they are interviewed is a decisive factor in them accepting the job and/or continuing the application.
They really care about their careers. For that reason they select their jobs carefully since they will spend more time in that job than other things -like family for example-, for that reason a good developer asks as many questions as he can to figure out how your team works, what are the main blockers and/or challenges your team is facing, what are the long term projects your team have, what is the dynamic / hierarchy within the product team, what are the spaces and opportunities to grow, etc.
In Drive: The surprising truth about what motivates us, Daniel Pink says that assuming that money is off on the table, knowledge workers are motivated by 3 things: Autonomy (control of what/how/when we do: which is true in an Agile environment), Mastery (constantly learning and evolving) and Purpose (when we feel that our job is important and we contribute to making things better). The assumption about putting the money off is pretty important since, when we have some high-priority need or we are in a critical/rushing situation, this will be the highest priority for anyone despite any other factors.
Based on that, good developers during the interview will:
- Pay attention to who the interviewers are: are those managers, developers, leaders, or architects? How many people are in the interview? There are developers in the interview? –in my opinion, developers are mandatory in each step of the application-.
- Observe if the interviewers are following a script with predefined questions, or if the interview is an open and flexible chat where they can explore and are encouraged to ask more questions openly.
- Notice if the questions are binary or open. If those questions are binary and tech stack related, then they realize that fixed tech stack has main importance for the product team. They notice that the team is not interested in good developers, instead, they are looking for fixed/closed tech stack experienced developers. A good developer is not interested in a place where the technology is closed and the answers are binary (with a high probability to listen a “no” to new ideas).
- Expect open conversations about real-world and concrete scenarios, exploring different approaches and solutions, and pair programming/coding sessions to expose his coding skills.
- They are looking for a job where they can apply good practices and implement new ideas, new alternatives and most importantly, learn. They also want to teach and share their knowledge, and contribute to a clear and measurable purpose with a high degree of freedom.
Probably in some next topic, I will explain more about my ideas for different approaches for interviews and processes for developers, at least for the technical interviews. As you can predict from the previous paragraphs, the technical interview is a decisive factor for the company and the candidate. I mean, as an interviewer you want to interview a good developer I guess, and good developers will decide based on many factors, and the technical interview is one of the most important points.
Finally here’s the post’s soundtrack. In this case, I’ll introduce you (if you did not meet him) to Luis Salinas. I spent so many hours listening to his music during my adolescence. A great musician. Enjoy 🙂