TechScreen

Technically Qualifying Without Being Technical

Technically qualifying without being technical

Speaking to a developer can be daunting for a recruiter. This is especially true for a junior recruiter, but self-confidence is not a surrogate for detailed knowledge even when you are talking about a veteran recruiter.

There are plenty of recruiters who kid themselves into giving themselves more credit than they deserve for being “technical”, but there are ways you can size up if a veteran candidate “gets it” or if they are a hack.

Recruiters are not engineers, but there is no reason you can’t cultivate your own gut-level sense of confidence to know if your candidate is really sharp or full of it. The key is understanding how to extract evidence of their competence — or lack thereof — without getting into the weeds.

The following are some questions you can ask to figure out which side of the fence your candidate with the strong resume stands.

1. You are building an e-commerce site from scratch. Walk me through all of the questions you will ask before you start writing code.

The key to this question, ironically, is to have them stay away from technical details. You want to hear them go into excruciating details as it relates to understanding the business requirements. In fact, if they even come close to describing the technical stack, you are talking to a complete hack. This is not an exhaustive list, but it gives you some ideas:

  • Is there a site right now that this new system replaces?
  • Talk to me about the current process of what happens when you sell something. What are the steps in order, who is involved, explain when money changes hands and how the transaction is reconciled?
  • Describe the systems you use for managing your inventory, ordering supplies, handling the accounting and tracking sales.
  • Explain what integrations exist between your current systems.
  • Are all of your sales direct, do you sell through channels or both?
  • Do you just sell products, or are there services?
  • Explain your pricing. Is it a standard rate, do you give volume discounts and what are the thresholds if you do?
  • Do you only sell in the US or do you also sell globally?

 

The point here is that a truly experienced developer or Architect is going to insist on understanding the boring business details in excruciating detail. The more granular and probing into the details, the more it becomes clear that they have done this type of things many, many times before. If someone begins talking about the programming language, the application servers and the database establishes the fact that is it Amateur Hour.

2. Describe the most complex system you ever designed. What made it so complex? What challenges did you hit that you didn’t anticipate and what would you have done differently?

 

  • This is similar to the previous question, with one major difference: Someone paid a ton of money for it and their decisions mattered profoundly.
  • One thing you are looking for here is honesty, thoroughness and a sense of perspective
  • A real professional will admit mistakes or assumptions that were off-target. Everyone makes mistakes, so you want to know if your candidate has some humility or if they have a swagger that says “I don’t make mistakes”.
  • If someone doesn’t say anything about what they would do differently, I consider that a big red flag. There are always a different way to do something or there are unexpected problems that come up. Saying you wouldn’t change anything either means you are full of yourself or you are not very creative.
  • If they describe something that doesn’t seem terribly complex, they are demonstrating that they either lack perspective or they have never been trusted with something extremely important.

 

3. If you consider the 5 following activities within the software development life cycle: Gathering requirements, Analysis, Design, Development and Testing, what percentage of time would you spend in each area?

 

There is no hard set percentage for each one, but you are trying to learn if they approach building something like a seasoned professional or a corner-cutting hack. The true professional will show themselves by assigning a huge percentage of their time in the analysis and design, with a seemingly small percentage in the development.

They will also leave a decent chunk at the end for testing, because the battle-tested veteran knows that unexpected problems happen, no matter how smoothly things seem to be going. Hackers are people who code by the seat of their pants in a trial-and-error fashion, and usually create more problems than they fix. Don’t confuse years’ of experience with expertise, because doing it badly for 10 years is doing it badly, period.

There is no single percentage or formula for answering that question “correctly”, but here is a guideline to know your candidate knows the score:

Gathering requirements: 10–15%

Analysis: 15–20%

Design: 30–40%

Development: 10–20%

Test/Debug: 15–20%

The key is to get an understanding of what side of the fence they are standing on, not understanding the gory detail of their work. Recruiters are not engineers, but you don’t need to be one to determine if a software engineer approaches their job like a professional or a hack.