I've been interviewing candidates for software developer positions for the past several years. It has been an interesting experience, and I thought I'd put down some thoughts about what I look for in a candidate, as well as how I perceive the current hiring/interviewing landscape.

I think the present interview processes used by many companies tend to lean too heavily on so-called DSA problems, i.e. data structures and algorithms. While I don't think improving one's skills at such problems is a bad thing, I do believe that emphasizing these problems doesn't actually lead to finding the most promising developers.

These types of questions are attractive because the results are easy to measure, but just because assigning a value is easy, it doesn't mean that the result corresponds well to the day-to-day work of a software developer. To me it's a bit like evaluating marathon runners by having them run a 100 metre sprint.

When I interview people, I try to look for certain qualities. Below I'll summarize the things I try to identify when I am interviewing a candidate.

Intrinsic Motivation

Being self-motivated means that a person's behaviour is driven more by their internal desire to perform well rather than by getting ahead. That's not to say that caring about compensation or career progression is bad, but if that is always the primary motivator, I consider that to be a negative.

Someone with intrinsic motivation will have an interest in software that goes beyond their job, and their portfolio will include interesting self-initiated projects. While this may be a somewhat controversial opinion, I don't think it's ideal if someone looks at software development purely as a career path, with no interest in it beyond the workplace.

That doesn't mean work-life balance isn't important: It's worthwhile to spend time with family and friends, be physically active, etc., but, if there is no innate interest in coding, I believe that will significantly limit a person's growth in the long term.

Unfortunately, I find that it's not uncommon for recent grads to aim for goals in an arbitrary way. In school, they focus on grades for their own sake, and after graduation, that same pattern appears to continue.

I think of intrinsic motivation as being a composite with the following constituents:

Curiosity

Curiosity is the desire to learn, both about technology and about the domain. This includes doing one's own research to acquire a greater depth of knowledge and understanding, with a focus on fundamentals.

This means not waiting to be spoon-fed an answer, and not to blindly trust received information, but to explore on one's own, bringing new understanding for oneself, but also for the benefit of the rest of the team.

Initiative

Initiative is the willingness to take things on without having to be told to do so, and to tackle problems more independently.

I like to see an overall attitude of being willing to do some leg work and not to expect to always be given a series of steps to follow by rote.

One should not simply stop when a challenge presents itself. This doesn't mean one should keep spinning one's wheels for long periods of time: It's okay to put in a reasonable effort, identify some specific areas that are causing trouble, and then to ask for help, but this should be done in a focused way.

In the workplace, an individual with initiative will identify pain points in the system and will be willing to make improvements themselves rather than waiting for someone else to do it.

Enthusiasm

I like to see a sense of excitement about the possibilities of building something great. This quality is related to many of the points above.

To be a good software developer, just being smart is, in my opinion, not good enough. Wanting to develop software, and to achieve a high quality in the software being built, is extremely important.

Communication

In addition to the above qualities, being able to communicate clearly (in code and otherwise) is both significant, and in my experience, rare.

I often find that understanding a piece of code can be more laborious not because it's so inherently complex, but because it's written in a way that doesn't do a good job of expressing the intent.

In design, there should be enough abstraction to separate logic into a modular structure, but without unnecessary complications and overly convoluted logic.

In interviews, I examine the candidate's ability explain their thoughts as they are working on a problem as well as their ability to write code that fulfills its objective as directly as possible.

Problem solving

At the end of the day, solving problems is still important, and the DSA-style problems attempt to target this aspect of software development.

In this regard, I want to see an ability to solve problems that are appropriate for the domain and for the candidate to demonstrate an ability to research appropriate techniques.

I'm not sure it's so critical to find the answer as it is to think through the possibilities systematically - and from my point of view, being able to search for a suitable solution online is also valuable. Having the ability to evaluate different solutions or explanations for a given problem, and understanding how to adapt a given technique or piece of code to the task at hand is often more efficient and more reliable in the real world than re-inventing the wheel.

I do think that emphasizing DSA problems in interviews poses some challenges. It may give the candidate the wrong idea about the type of work they'll be doing. If someone is especially motivated by small tricky problems, they may not enjoy the reality of everyday software development - and someone who is not motivated will not do a good job, regardless of how capable they may be in principle.

Getting too accustomed to such problems can also lead to a passive posture of accepting constraints and powering through them, whereas in real life one can often simplify a problem by relaxing or modifying some of the constraints. What really matters is whether the software meets its objective from the point of view of the key stakeholders and users.

When people spend huge amounts of time working on DSA problems, it also incurs a significant opportunity cost: People could be using that time to come up with, and work on, their own projects. Personally, I think that’s generally more valuable

The fact that these types of DSA assessments are so ubiquitous also leads to a kind of arms race where the problems need to get harder over time, since candidates are actively preparing for them. At a certain point, the results don't measure someone's talent or potential. Rather, they are an indication of how much time a candidate has spent on such problems.

Alternatives to DSA

My preference for interviews includes things like the following:

• General programming: Evaluating the candidate at a a broader task that's relevant to the domain (possibly pair programming), including working out tactical aspects of the problem like efficiency, but also how to structure and organize the code, as well as some higher-level strategic aspects of the design. If a problem can incorporate elements of finding needed information the interviewee is not familiar with, that’s a nice bonus.


• Take-home assignments, where there is less time pressure.


• Lastly, using the interview to go over some of the candidate's own projects with them appeals to me.

That said, none of these approaches is a panacea. One great advantage of DSA problems (and similar puzzle-oriented questions) is that an organization can collect a database of thousands of such problems, neatly categorized both by difficulty and topic area. While preparing for such problems helps, if a company plays its cards right, it's less likely that a candidate will know the exact solution ahead of time for a given question, even if they've looked at a lot of problems.

It's a lot harder to set up a large bank of more general programming or take-home exercises that can be deemed comparable to one another in terms of difficulty. For take-home assignments, the company is also imposing a significant burden on the candidate to work on something offline, which may not always be fair - and it's also easier to game. As for personal projects, if evaluating them becomes common, it will also encourage candidates to game the system.

Unfortunately there is an inherent tension between making something objective and systematic on one hand, but also difficult to game on the other hand. A relatively small company may be able to get away with an interview that's a bit more subjective, and not have to worry so much about candidates finding out what the questions will be ahead of time. However, for higher-profile companies, candidates are constantly trying to find out what they can do do pass the interviews, so scaling the evaluation process will always remain a challenge.

I do think that a more multifaceted approach, one that doesn't over-emphasize DSA, with several different types of questions given equal weight, is best. It's also important to find ways to measure how effective newly hired employees are, a year, two years, later, and to feed that information back into the interview process - although performance evaluations pose their own challenges.

Conclusion

I find the following video showing a competition between Magnus Mitbø, a world class climber, and the "Norwegian Hulk", a strongman competitor, interesting: It shows that even something that may seem simple, like physical strength, is multi-dimensional, and not amenable to a simple scale going from "weaker" to "stronger". This is certainly true for software development, or any complex task for that matter.

It's important to recognize that a kind of monoculture in hiring where everyone has the same strengths and weaknesses will expose vulnerabilities and gaps within an organization, so it's very valuable to appreciate the variety of talents different people have and to hire with that in mind.