A post on AlleyWatch proposes a way for a non-technical person to qualify and hire a developer. It presents, among other things, a list of 10 interview questions to ask prospective candidates. The problem, though, is that the author makes some fundamental mistakes in my mind, and is trying to avoid hiring multiple people for multiple jobs.
Multiple Jobs, One Person?
While some of the questions in the list are fairly benign, there were 5 of the 10 that have several problems. The biggest, though, is that they describe multiple different jobs, and not a single job that is suitable for a single developer. The first hint that this is multiple jobs? When you reach questions #4 and #5 in the list:
4. “Do you see yourself as a project manager, a developer, or both?”
5 “How would you manage a team of programmers?”
These questions, plus the author’s discussion, points to two different jobs: software development manager, and software developer. Sure, there are a small handful of developers that find themselves suited to managing teams of people. But almost all of the good managers I’ve seen or worked with aren’t, or weren’t, hardcore developers themselves. There are always exceptions, but they have a skill at managing projects and people. These are not the same skills needed to design and write good code. Again, sometimes you can find one who can do both. Often, you can’t.
Too many companies are disappointed when their star developer turns out to be a dud of a manager. They are shocked that someone that is “that smart” can’t make the transition from building software to managing teams of people. And those people who are shocked need to pay more attention to the real world: being a manager and being a “do-er” aren’t the same thing, and the skills don’t transfer. Managing projects and people is about balancing resources, risks and requirements, it is about identifying obstacles or missing resources, and removing the obstacles and finding what is needed to fill the gaps. It is about guiding and motivating the people, not just tracking resources and deadlines. That has nothing to do with designing software architectures, selecting technologies and putting together a system to meet technical, business and non-functional requirements.
But There’s A Third Job
However, a 3rd job is identified in the questions, specifically in question 8:
8. “What would you do to ensure that our servers are up 100 percent of the time?”
While the question would contain significant issues that would have to be addressed in the software, to successfully keep a system on its feet requires a strong systems operations or administration person. Again, this isn’t a software developer. These are people who manage system configuration, perform testing on different patches or 3rd-party components in advance of deployment, and know about the care and feeding of systems. They focus on things like redundancy of different hardware components. If the system is running on a cloud service, you still need a strong operations person to manage the relationship with the hosting provider, to keep the metrics, to monitor your own software, and to speak the hosting provider’s language. That isn’t a development job.
This person works closely with the developers so that the software components required to maintaining the up-time targets have the resources they need. They also need to provide the non-functional requirements to the developers to be able to provide logging and tracing to solve problems when (not if, don’t be naive) they occur. This is part of the whole “dev ops” thing, which is a welcome change in the industry. Operations, like QA, needs to there from the start, not just as an afterthought in the whole process.
Naive Approach To Software Development
There was a statement in one question’s discussion, and specific questions, that troubled me in the piece. The specific comment was in question 4:
I want a developer who can follow exact directions so they can build what we need.
The problem? Your directions aren’t nearly as exact as you think they are. You can’t give someone a list of items, say “build this” and not expect questions and feedback. I guarantee that, other than some vague statements on “be up all the time” and “handle lots of users”, the non-functional requirements have been given short shrift. Even the functional requirements are likely incomplete. They may sound “exact” from the standpoint of the marketing or branding teams, but they are likely less exact when it comes to actually figuring out what to build.
In fact, any list of features and requirements not built with developers, QA and operations in the room is incomplete, inexact and possibly wrong. Everyone involved with them has to be together when the requirements are crafted. Each team (marketing, branding, business ops, support, development, QA, system operations) brings important experiences and vital ideas to the table, but all with different perspectives. Having any one of those groups build the requirements in isolation is a recipe for failure, not success. No single group in the business has the complete picture.
But the previously-quoted statement, along with a pair of questions, points to a larger problem with the author’s position.
6. “How you would fix these issues?”
7. “I need this done over the next couple of weeks….”
Both questions basically ask the candidate to provide estimates and plans of action on work items. However, these are entirely unreasonable and completely unfair. Why? Because they are for requirements that the candidate hasn’t had a chance to explore in any depth, in a business they may or may not have any experience in, and for a system that they’ve never seen and never worked with. To turn it around, imagine if I asked the author, whose focus is marketing, sales and business operations, to “estimate the time, cost and effort to build and execute a marketing plan to sell something and have nearly 100% satisfaction from your customers?” Yes, that’s the entire question. No indication what is being sold, who the customers are, and what might make them dissatisfied. A smart person would basically laugh at the question, because it is so vague as to be meaningless. There’s no way an intelligent person would try to answer it without asking a lot of questions first.
So would any technical candidate asked the questions quoted above. My answer, after having played this game for 3 decades, is to simply say “I’d need to understand things in far more detail before being able to provide any sort of plan or estimate on work”. There is no other acceptable answer. Anyone who starts to lay out plans and estimates, and provide guarantees, should be asked to leave. Anything they say is a pure guess, and the only conclusion you can draw is that they really shouldn’t be doing the job.
Any answer other than the one I’ve provided means they are being dishonest in some way. You cannot answer the question with any detail or certainty, or honesty, without a lot more information. Anyone who tries to answer is either so nervous they don’t realize they should just stop, or is a BS artist hoping to fake their way through with an answer you might like and sounds convincing. Either way, they are probably not the right person for the job.
But the author expecting an answer to both questions tells me that the client in this case assumes that software is easy, that “anyone can build anything, even if they don’t know what it is yet”, that this is like ordering a hamburger at Five Guys, and that deadlines can be set in advance. They also believe that estimates are a statement of fact, and form some kind of contractual obligation (even if only a social/informal one), and not hitting the deadlines means you can’t really code properly.
The result is a perception that a missed deadline isn’t a problem with requirements or estimation, it is because the programmer can’t do their job right. Given the author’s discussion on this point, this leads me to believe they may have been a big part of their problem in the past:
I have hired three programmers who all seemed fantastic and brilliant during their interviews, but ultimately couldn’t deliver. I always blamed the programmers (it was their fault for misleading me about their true abilities).
The author hints that maybe they are part of the problem (“maybe the fact that I’ve had the same experience three times means it had more to do with me than I would like to admit”), but omits their likely culpability in a flawed underlying process. And it isn’t the necessarily the hiring process. Bad requirements, leading to poor estimates and unrealistic deadlines and expectations, are a major cause of failed software projects. It isn’t the programmer’s skill. It was that they were asked to do more than was expected, and the expectations were unrealistic to begin with. Sure, there are bad programmers out there (and more than we probably care to admit). Maybe he really did hire 3 duds. But even the best programmer is going to fail if the rest of the process is a recipe for nothing but failure in the first place.
Are They Doing It Wrong?
I really see two problems with the questions, the process outlined, and everything they imply. First, it assumes that software development is something simple, that can be done “on demand” like ordering a hamburger at McDonald’s, or like providing your list of ingredients to the sandwich artist at Subway. Software development, unfortunately, isn’t in a state where we can put vague requirements in one end, turn a crank, and get fully-functional and perfectly reliable software out the other end. It means being realistic in your expectations, using the right tools and processes (right depending on what you’re trying to do), but more importantly, building the right team.
In the case of the author’s situation, it sounds like they needed to hire the development manager first. The questions hint at needing a team, so you need to hire someone to run that team. That person should then be able to find the right developers, QA, operations and other staff to fill out the team to build what is needed. Expecting a single person to do it all up front is optimistic, and naive to a degree. Sure, there are some that can do it. But they are few. I don’t hire a single person to build a house in a useful timeframe. I have framers and drywallers and electricians and plumbers and finishing carpenters and roofers and painters and on and on. Sure, one person can do it, but it will take a lot longer.
So why would you expect one person to be able to architect, design, code, test, deploy and manage a system, oh, and manage a team of people while doing it? If it’s a small system, one person can probably do it. Anything with any sort of complexity needs developers (possibly with different skillsets and experience), QA to make sure it works, and system operations people to keep it running. All of them have to work closely with the business and marketing side, as partners, not as subordinates to follow orders. They also need a manager looking over all of it to keep the team cohesive and moving in the right direction.
The approach outlined isn’t the secret to hiring “the best programmer available”. I’m not sure what they’ll accomplish, but if they do manage to get someone good out of it, is because of luck, not any particular magic in the questions or the approach. It really isn’t scalable, and it certainly isn’t repeatable in my mind.