I interview web developers. Here’s how to impress me.
I have seven years of interviewing experience with web developers. I’ve seen the good, the bad, and everything in-between. Here’s some of what I’ve learned to look for when interviewing web developers.
Don’t just know what — know why.
So you know every tag in HTML 5. Great. Do you know why you’d use an article instead of a section? You’ve studied up on AngularJS, but can you list a good real-world use case on an average project?
Imagine a mechanic charging you $20 extra for an oil change for a new, experimental oil, but not being able to tell you why that experimental oil is better for you. If you can’t explain why your technologies are important, that’s what I’m afraid you’ll do. I need to be given a reason to believe that you know when to use — and when not to use — the technologies you know to more effectively solve problems.
Knowing why also shows me that you’re involved in the ongoing discussions in our industry. Our industry is always growing and changing. If you’re not deeply involved with it, you will get left behind. Knowing, and voicing, why your knowledge matters shows me that you don’t just know today’s technology, but you’ll know tomorrow’s technology when it becomes available. That trait is just as important as knowing the technology in the first place.
Be a king or queen of the basics, not a jack of all technologies.
Know how to solve business problems, not just technical problems.
Come in with at least one example where you helped meet a business objective in a way that no one else could. Good developers follow processes, but great developers can identify problems with existing processes. Good developers give the client the solution they want, but great developers suggest new solutions to reduce project costs and timelines. Where have you gone beyond the initial request?
In the end, our jobs are about two things: time and money. If we can’t save the client one of these things, we’re not experts — we’re just code monkeys. These are the problems that management deals with daily. If you can show that you can help us with these, you’re a lot more likely to land a spot on our teams.
In communicating these, focus on the numbers. Don’t tell us you improved the process — tell us how many hours you saved your team. Don’t tell us you started A/B testing some of your sites — tell us how much you improved on-site conversions. The numbers are what matter, not the initiatives. That’s the language of success.
Know what you need to work on.
Ask a street fighter what he needs to improve about his fighting style and you won’t get a solid answer; but ask Rhonda Rousey what she needs to improve and you’ll get a very specific, very real weakness that she’s aware of and working on fixing. True masters of their craft are acutely aware of their shortcomings and the gaps in their knowledge. It’s the amateurs who don’t have any weaknesses.
You may or may not be asked about things you struggle with; but whether you provide them or not, we’re always looking for them, and we are very good at finding them. In fact, when you do tell us what your shortcomings are, it’s usually not a surprise to us. When we encounter someone who either isn’t aware of or isn’t willing to admit their shortcomings, that’s a good sign that they’re not ready to move up to the next level. It shows a lack of awareness and preparedness that concerns us.
The best course of action, once you know what you need to work on, is to be honest about it and tell us what you’re doing to fix it. Chances are we already noticed your lack of organizational or communication skills. Owning it makes us feel better about you as a candidate.
Know what you want.
I’m amazed how many developers I talk to that just want a job. Not a good job. Not a job with ample room for growth. Just any job. This is a big red flag for me because it shows me that you hold no loyalty to this company and job, and will jump ship at a moment’s notice because you don’t know what you want until you see it. I even talk to developers who will change what they want after they hear the job description. (That doesn’t work, by the way.)
Give thought to what you want right now: what company culture and perks, what type of projects, what type of clients and coworkers. If it doesn’t match our company, you’ll find out now rather than six months into a job that you hate. If it does match our company, you’ll have an edge over people who don’t know what they want. There’s no downside to knowing this.
And don’t stop there. Look at career path options and figure out where you want to be in two years, and five years. We’re always looking for the next team lead or technical architect, and that can influence our hiring decisions. And if you just want to be the best developer we’ve ever seen, that’s useful too. If someone tells me they want to be the best developer in the company within three years, that gives me a lot more confidence in their passion and longevity than someone who doesn’t know what they want to do. Always error on the side of ambition.