Key Takeaways
- Learning how to evaluate Web Developers properly has proven to be one of the most important tools for ensuring that the highest-quality work is delivered to stakeholders and users.
- Emphasis is often too narrowly placed on tactile skills when code alone doesn't reflect an individual's proficiency in teamwork, adaptability to challenges, or collaboration skills.
- It's crucial to understand that applicants at a higher level may be unable to reveal specifics of their finest work because of nondisclosure agreements (NDAs) and the safeguarding of trade secrets.
- Finding a Developer with the precise experience you seek may be challenging, yet those with similar backgrounds can be equally beneficial. Their value is particularly pronounced if they show adaptability and a keen eagerness to learn.
From small, local eateries to large, multinational corporations, every business today needs the talent of Web Developers to compete online. Yet it can be incredibly challenging to find great people to fill these roles because even many of the best and the brightest out there are self-taught. These individuals can be incredibly valuable and talented, but they might easily get lost in the shuffle of candidate review and application systems with overly rigid requirements and rules.
As a leader of Aquent's Web Development Team and previously the Director of Web Marketing for a university, learning how to evaluate applicants properly has proven to be one of the most important tools in my arsenal to ensure my team delivers the highest-quality work to stakeholders and users.
Two critical strategies for building web development teams
Within a Web Team, the roles and required skills of Developers can vary widely, covering a broad spectrum of responsibilities and expertise. Often, emphasis is too narrowly placed on the very tactile skills: coding, design implementation, how many and which frameworks they know, and which deployment stacks they've worked in. These are, of course, important, but they also can hide equally important soft skills.
Web Developer soft skills
In day-to-day work, a Web Developer must have good communication skills, an understanding of user behavior and expectations, and a keen sense of investigation to determine specifications from design and content strategy that inform the project. The old jokes of the past no longer hold true—talented Web Developers are both masters of their craft and masters of the human experience that results from it.
I've consistently regarded soft skills as the top priority when interviewing candidates for a position. Assessing their code is straightforward; it narrates their problem-solving approach and reveals much about their methodology. However, coding skills still need to be taught when starting a new position. Even a highly skilled Senior Developer must adapt to your specific processes, tools, syntax, styles, and perhaps even new programming languages upon joining your team. This adaptation is inevitable. Yet, code alone doesn't reflect an individual's proficiency in teamwork, adaptability to challenges, or collaboration skills.
Diversity in Web Development Teams
This is one of the reasons that building a team with a diversity of backgrounds and experiences can be very beneficial. That is a catalyst for helping your team culture adapt and integrate with others. It sets a strong foundation from which they can learn to listen and accommodate other people's lived experiences, training, and problem-solving abilities. Homogenous groups might prove highly productive in cases where the challenge fits their niche. Still, over time, you'll find that they can be rigid and brittle when they run into a scenario that demands reading into a bigger picture.
Such an environment can lead to solutions that miss the mark, failing to address essential needs and potential opportunities. It can also lead to problems down the road due to cargo culting. In the development world, cargo culting means “doing a thing over and over the same way because it ‘works,' but without understanding why.” Over time, there might be a better solution. Or maybe a more performative approach. A team built on sameness, though, will tend toward doing things the way they've always been done, which can result in missed opportunities and stagnation over the long term.
How to assess Web Developer candidates
Winnowing down a candidate pool can be a challenge if you aren't as familiar with the technical landscape of web development. What tools show dated skill sets? How do people hide a lack of experience? Resumes are ultimately very short (or should be) and provide a limited view into how good (or not so good) a candidate might be.
Junior Web Developers
Generally, a resume should easily fill a page. Even a Junior Web Developer should find it easy to fill a page with their background and experience, both within and outside of web development. If it is overly short, that likely is a sign that they simply don't yet have the depth you might be looking for in a hire. This is especially true for entry-level positions, which might be someone's first position.
Even a new entrant into the job market can have examples of work on freelance projects, personal development, engagement with open-source projects, or participation in coding boot camps. These are all ways people develop their talent to prepare them for professional work, and the more junior the role, the more I hope to see things like that, demonstrating a hunger for the field.
Mid-to-Senior Web Developers
For more mid-to-senior roles, it's not unusual to leave those efforts off in exchange for their hard-earned professional experiences. Don't just look for names of tools or programming languages. See if they discuss working with stakeholders and engaging with Design and Content Teams. Always keep an eye out for references to user experience (UX) design or human-computer interaction (HCI), as those demonstrate efforts at building effective tools for users, not simply meeting project specifications.
Also, it's important to remember that higher-level applicants might not be able to show you some of the details of their best work due to nondisclosure agreements (NDAs) and protection of trade secrets with previous employers. However, you can always ask for a link to a Git repository or something like that, which can be reviewed by other engineers on the team so that you can get feedback on their technical prowess. That peer-level code review will help you gain important insight from the people who know the most about your existing code and whether or not the applicant appears to be producing at a level equivalent to the role.
Translating experience and skill sets
Your environment is undoubtedly built on various tools, processes, and frameworks. Ensuring that the applicant meets those needs is largely a matter of matching the keywords from the resume, and exploring their experience level. Always remember, it's unlikely that you'll find Cinderella to step into your shoe, but similar experiences are still valuable, especially when they can demonstrate flexibility and hunger for learning. If you need an Angular Developer but are interviewing someone with years of React experience, it's worth exploring that with them, as they may readily be able to translate that skill set easily.
One final note on evaluation: I personally value a degree. That doesn't mean not having one is a deal breaker, especially if they can demonstrate their skills effectively otherwise. But, I see that degree as a sign that they have the ability to commit to a process, that they know how to learn and seek out knowledge (very important in an ever-changing and evolving industry), they've likely had to collaborate with large and small groups, and they can finish something important to them.
What type of degree they hold, I find, is much less important. A music major can be just as talented a Developer as a computer science major. It just so happens that I was a communication major with an emphasis in theatre, but I've built websites since the 1990s. Everyone's journey is going to be different, so consider how much weight you put on the details. This has just been a particular approach that has served me well.
Web Developer interview questions
Regardless of the position's level, I always like to do a simple run-through of some common acronyms, names, and baseline networking knowledge. It's not always important that they can answer everything, but how they answer can tell a lot. Are they thoughtful, accurate, and well-versed, or are they trying to fill time?
What have they been exposed to previously, or completely unfamiliar with? I want to give them an opportunity to explore an answer for me, not just list functions, test frameworks, or their favorite integrated development environment (IDE). For instance, I might ask them about the stages of an HTTP request or to describe how CSS specificity is calculated. I'll ask them to describe a MEAN stack, or the parts that make up Web Vitals. Can they describe what the Document Object Model (DOM) is or how a shadow DOM works in a web component?
If they appear to be well-informed about the fundamentals, then you can increase the complexity:
- Describe how you would set up a build process.
- How would you debug a certain type of JavaScript error?
- What would your approach be to troubleshooting poor optimization of a slow-loading page?
Think of it like being locked in a dark room—one of the first things you would normally do is feel out where the walls are, how big the room is, and where the doors and windows seem to be. Once you've figured out the boundaries of the space, you can start probing those doors and windows for more. Find the applicant's doors and windows, and continue your exploration from there.
The trick is to give them more abstract questions. It will help them feel less cornered if they aren't heavily informed on a topic, and it gives you a chance to see the way they think through an issue in real time and communicate their thought process. I have tended to find this substantially more useful than something like a coding challenge. You can see how they code from past examples easily enough—what matters is how they approach a problem and how methodical their steps are for tackling it.
For instance, one question that I love to ask is to find a particular project or tool they are passionate about, and have them walk me through how they settled on it, and what it was that jumped out at them to put it into production. Letting someone walk you through work they did that they found exciting will help them feel more comfortable and should result in a wealth of information being volunteered that you might not have thought to ask. It can also provide callback points you can use to ask how they might do something similar to your environment.
Lastly, as a fun little cool-down question, I ask them what they think of our website. Where do they see an opportunity for improvement? What impressed them? Was there anything they found particularly interesting or novel that they hoped to learn more about if hired? See if they catch anything you know of that's an issue. You can also get a feel for how much research they've done about your company this way because, hopefully, they've at least scanned the website a little to know what they might be getting into. This gives them a last chance to show off for you a little, and the open-endedness will let them play to their strengths. Do they emphasize usability and accessibility? Do they note bad page performance? Were there features that worked incredibly well for them, or were missing entirely?
Ultimately, you're exploring the applicant, so set them up for success. Don't try to stump them with questions. Instead, be flexible and follow their lead a little, depending on where their strengths are. If a weakness is identified, note it and move on, as there won't be much to gain once you've noticed it. Let them talk as much as possible because that's how you are going to learn about them. In the end, you're hiring a person, not their code.
