When I got my first programming job, I was in awe of the technical savants who knew the coding languages inside out. I thought that was something to strive for and that was ultimately what made a great software developer.
Twenty years later, I’ve worked with a lot of good developers, some great, and some downright awful. One of the main things I’ve learned is that technical acumen doesn’t necessarily translate to a great developer. It may not even correspond to a voucher. It’s just one piece of the mix that tends to be overstated when interviewing job candidates.
[ Get exercises and approaches that make disparate teams stronger. Read the digital transformation ebook: Transformation Takes Practice. ]
So what should you be looking for? I found seven traits that stand out when trying to identify true IT talent.
Key developer skills, with related interview questions
I have known very sharp technologists who fall flat on their stomachs when it comes to solving problems. To be an effective problem solver, you need to match the right solution to the problem at hand.
Best practices are what we all look for, but these are guidelines.
I worked with a developer who was so committed to best practices that he couldn’t meet a deadline. Best practices are what we’re all looking for, but they’re guidelines – not something we should be slaves to. You must have the flexibility to balance the business schedule with technology requirements to arrive at a workable solution.
Great developers realize the technology is there to support the business. They develop elegant solutions that can grow with the business and make people’s lives easier.
“You and two other developers had two hours to come up with a solution to automate a manual process. Files arrive in Box, which are manually fed into a Windows Forms application that populates the records into a database at the click of a button. You have the source code of the application. How do you approach automating this end-to-end process within the tight timeframe? »
[ Want DevOps best practices? Watch the on-demand webinar: Lessons from The Phoenix project you can use today. ]
2. Ability to ask the right questions and listen
Often the product owner only has a vague idea of what they want in a system or feature. It’s a start, but this mess of ideas needs some help being pulled together into usable requirements. It is essential not only to listen to what they say, but also to anticipate what they have not yet thought of. It can mean the difference between delivering a successful project and having to restructure it mid-stream.
By thinking critically about the request, you can ask targeted questions to resolve issues. This can save countless hours of writing code that targets the wrong thing.
“Tell me about a time you developed a feature for a user and when delivered it wasn’t what they wanted. Where was the disconnect and what did you learn from that experience? »
3. Willingness to jump into the fire
Despite our best efforts and careful preparation, things will go wrong. Systems will fail. How many times have you heard:
- “It’s not my program.”
- “It’s a problem with the server. The network administrator must solve this problem. »
- “I can’t help but the database server can’t handle the load.”
When a bug brings the company to its knees, great developers don’t come out with a parade of excuses as to why they can’t help.
When a bug brings the company to its knees, great developers don’t come out with a parade of excuses as to why they can’t help. They are leading the charge to find a solution. Often they have their feet in the fire and they are furiously scrambling to get the system back online. Other times, they don’t solve the problem directly; instead, they help stimulate ideas or provide valuable support that leads to resolution. Great developers find ways to be indispensable when it matters most.
“You receive a call from your project manager at 6 a.m. that your web application is experiencing intermittent access issues by the user community. At first glance, this looks like a problem with one of the network team’s managed load balancer VMs. How do you proceed?
[ Can you explain why orchestration tools matter to enterprise IT? Get the PDF: How to explain orchestration in plain English. ]
4. Be a great team member
A great maxim to live by is that if one team member fails, we all fail. The benefit of being part of a team is that everyone brings a unique set of talents and experiences to the table. A developer may be struggling with a feature that another developer might skim through. When teams collaborate effectively, we reduce these individual struggles.
Great developers actively reach out to their team when they encounter roadblocks or want feedback on a proposed solution. By letting go of tunnel vision and keeping an open mind, we can rely on our fellow developers to find better solutions.
Look for candidates who thrive in a team environment. It can be difficult to integrate lone wolves.
“Describe a time when a team member was struggling and you proactively reached out to help.”