The Complete Software Engineer Assessment

Conducting a Complete Software Engineer Interview Assessment

How long does it take for a software engineer to drive to Minneapolis?

That's a great question. While I haven't asked, I suspect most people who interview software engineering candidates could figure it out. But they'd have to ask a few questions of their own first.

  1. Where is this engineer at the current moment?
  2. What is their current velocity?
  3. What is their rate of acceleration?

With these three bits of information, it's a fairly simple calculation. It is well known to those with a basic knowledge of calculus that the first derivative of position with respect to time is velocity, and the second derivative is acceleration. Position is simply location at a snapshot in time.

Hiring a software engineer is a bit like attempting to solve the question posed above, except that now the location of Minneapolis is no longer stable. It is moving at an unknown velocity and an unknown acceleration.

Assessing a Software Engineer's Position

Evaluating the current position of an engineer is the easiest part of the hiring equation. This usually involves delving into a candidate's education, their experience, and job-specific skills. You can determine their level of knowledge around any number of frameworks, technologies, and processes. While this information is useful and necessary, it doesn't tell the whole picture. It only tells you where the engineer is at this moment in time.

Unfortunately, this is the point at which many technical evaluations stall. Many interviewers never get past evaluating the current position of the candidate. They consider the job-opening and the candidate as two static positions, and simply look for the candidate whose current location is closest to the location of the current job opening.

This is a recipe for failure. There are no software development job openings with static success criteria. There never has been, and there never will be. (I'm using a somewhat loose interpretation of "never.")

Assessing a Software Engineer's Velocity

Evaluating the velocity of a software engineer is significantly more valuable in predicting future performance, but is also much more difficult to assess. This step of the assessment involves delving deep into specific accomplishments and attempting to objectively quantify them against the context of their career trajectory. Accomplishments that would be considered incredibly impressive for a somewhat junior developer may be considered routine, or even mandatory for a senior developer.

Additionally, the interviewer is attempting to calculate the rate at which this engineer is able to consume and digest new information. Often, these measures are much less objective and more prone to error than simply determining a candidate's current knowledge.

This step also involves testing a candidate's intelligence, problem-solving, and analytic skills. These types of tests are often more time consuming, somewhat more subjective, and often more difficult to administer. However, they too are an absolutely necessary part of the assessment.

Assessing a Software Engineer's Acceleration

Conducting a velocity assessment will give you a much better idea of an engineer's capabilities than strictly a positional or snapshot evaluation. However, it is still not sufficient. Technology targets are not stable entities. The required skills of tomorrow's software engineers are unknown. Tomorrow's technologists will need skills in technologies that don't even exist today. To assess a candidate's ability to accelerate toward the technology targets of tomorrow, you need additional evaluation criteria. This involves assessing a candidate's competencies such as creativity, resourcefulness, influence, initiative, intellectual-curiosity, judgment, decision-making skills, motivation, passion, and self-awareness.

Summary

A complete assessment will help you find those elite software engineers that are productive today, and yet will continue to lead and set the technology direction of tomorrow also. Do not settle for the easiest path to interviewing software engineers. Conduct your due-diligence in your quest to find accurate assessments that will help you calculate the velocity and acceleration of incoming software engineers. Failure to do so will cause you to be continually missing the technology targets that are required to run a business in the modern era.


Thanks for reading (this sentance)! This is the section where I ask you to do things that will have no apparent benefit to you (like sharing this article). However, if you thought it was a good article (I was going to say 'great article', but figured that I would probably be setting the bar too high), sharing it will make you look smart amoung your friends. If you thought it was terrible, you could still share it (and ask your friends if they think it's as terrible as you do). In either case, you will continue to impress your friends with your ability to discern a good article from a bad one. And as a side benefit to me, it might increase (if only for the briefest moment), the incredibly meager visitor traffic and rather terrible SEO ranking that is currently possessed by this site.

However, if asking you to share a bad article (or even just an 'OK' one) would cause too much damage to your stellar reputation, you can still help more anonymously. If you found the slightest thread of value in this post, you could read one more article from this site. This would help my bounce rate, which is hovering just under 100% (if you're not familiar with the metric, that's a pretty poor number). Of course, if you found this article totally worthless, I would suggest not coming back. While the quality of the articles may improve as I get more practice, I really doubt if they'll improve enough to change your mind.


Vote on HN

Related Posts


Books You Might Like


Previous Index Next