5

It appears that many interview related questions on this site are focused on testing traditional CS knowledge, such as:

  • Algorithms
  • Data structures
  • Programming language/environments

Obviously the site is called "programmers", so that is to be expected.

However, I'd also argue that there are many other aspects that may be better predictors of a candidate's success (assuming that the candidate has a degree in CS from a good school and got good grades):

  • Do they have a general love for programming and a continual interest in improving their skills?
  • Are they willing to learn new skills?
  • Are they willing to take the time to share their knowledge with and help others?
  • Do they have a track record of success?
  • Will the interviewee enjoy the type of work the company is doing and be dedicated to it?
  • Did they work on similar projects or for similar companies before and enjoy them?
  • Will they like the company's culture?
  • Are they committed to seeing projects succeed?

Is there more benefit in testing CS knowledge or behavioral aspects, or a combination?

3
  • All? This question is difficult to answer as it covers all aspects of jobs in general. Consider condensing the question down to something directly programming related.
    – P.Brian.Mackey
    Commented Oct 13, 2011 at 16:30
  • Just wanted to clarify that the behavioral aspect questions above are not necessarily intended to be specific questions for the interviewee, rather the intent was just to give examples of qualities to assess in the interview. For example, to gauge "love for programming" you could ask about side projects, etc. -- preferably something specific to the interviewee.
    – Cliff
    Commented Oct 13, 2011 at 17:52
  • There are probably benefits to both, depending on the context. It is difficult to tell what is being asked here.
    – azheglov
    Commented Oct 13, 2011 at 18:44

8 Answers 8

Reset to default
5

Many employers are starting to value 'mindset' over 'skillset'. See this article:

http://finance.yahoo.com/blogs/daily-ticker/3gs-mindset-over-skill-set-critical-landing-job-125910227.html

It doesn't really state whether this has extended to the IT industry (which is very skills focused) but I happen to think it is as, if not more important. But I would take it beyond being willing to learn new skills, I think they should also learn new skills off their own back, and bring that knowledge into the enterprise. And of course, a love of programming is important, as is a general love of problem solving (do they like doing puzzles, to relax for example?)

6
  • I still like my bridge builders to have the basic required skills in civil engineering. I like my plane builders to have a basic knowledge of aeronautical engineering. I don't think software engineering is any different. Without the right skill set it may work in the short term but in the long run you are going to make a big mess that somebody else needs to clean up.
    – Loki Astari
    Commented Oct 13, 2011 at 16:39
  • 1
    I wasn't saying that they shouldn't have the skills, just that it's worth employing people if they show the ability to acquire the skills. After all, nobody graduates from college with all the skills to be a professional developer.
    – Paul T Davies
    Commented Oct 13, 2011 at 16:41
  • 2
    @Loki Astari, Thinking back on all the major screw-ups/messes I've seen or been involved with the root cause was never because of a "lack of specific skills" in any one team member. The messes were often caused by something related to how people work with others and make decisions. In other words, something behavioral. On the other hand, projects with the very best outcomes frequently overcome skill-set limitations in one/all team-members. Software engineering still has a long way to go before it becomes as mature a discipline as other more traditional engineering fields.
    – Angelo
    Commented Oct 13, 2011 at 17:22
  • I have seen some project failures because no one on the team could solve fundamental CS problems is a reasonable way.
    – kevin cline
    Commented Oct 13, 2011 at 18:20
  • @Astari - but, could an interview really have detected the behavioral/political problems, which usually not one person who is plain crazy, but people with different motivations, incentives, and personalities failing to work well together? Most people think they can detect these kinds of things in an interview much better than they really can. Testing skill is hard, but much, much easier than testing "mindset".
    – psr
    Commented Oct 13, 2011 at 21:02
6

When you are asking about behaviour in a technical interview, it ceases to be a technical interview.

For interviewing in general, both are extremely important I think. In my experience many companies hold a purely technical test (as they can be easier to do in a short time for many applicants) which you must pass in order to get to the real interview, where they ask behavioural questions.

1
  • Thanks for your answer. I meant to say "interviews for technical positions" instead of "technical interviews", so I updated the title to reflect this.
    – Cliff
    Commented Oct 13, 2011 at 16:30
3

Software engineering is VERY different from other engineering fields.

When building a bridge the laws of physics are constant and there are generally only a handful of fundamental acceptable ways to design and build a bridge. There are thousands of ways to design and develop just web applications alone, each one of those ways requiring a different skill set.

The mindset of a software engineer however overlaps the technological and platform barriers and allows one to view a persons general experience, attitude, behavior, design decisions and opinions, and ability to learn new skillsets quickly.

Mindset is by far and away much more important to me.

2

Even a 100% technical interview are affected by how the candidate behave when he answers the questions.

However, it's true that too much interviews are essentially based on technical skills and should include the others skills that are essential to every great programmer.

I passed many interviews and there were a wide range of genres. Some companies never asked me a single technical question while others focused their time on ensuring that I knew the most advanced things.

My personal experience is that companies that focuses on behavioral questions tend to get less job hoppers and people with essential skills such as emotional intelligence (which is rare for a developer).

So I would say you should combine both but with more focus on behavior.

3
  • The whole point of a technical interview is how they approach the question. Unless of course I really need somebody who can reverse a string, or swap two values with a temporary !
    – Martin Beckett
    Commented Oct 13, 2011 at 17:17
  • @MartinBeckett: yes, that's the meaning of my first sentence. However, I passed a number of interviews where looked more like a MCQ.
    – user2567
    Commented Oct 13, 2011 at 17:28
  • yes I was agreeing with you!
    – Martin Beckett
    Commented Oct 13, 2011 at 18:19
0

A combination.

The problem is that it is relatively easy to test a candidate on algorithms and programming language knowledge but it is very difficult to find out his behaviour after only one or few interviews. In most of the questions you raised the candidate may lie just because he wants to get the job.

0

A combination will be used often as how you answer can be just as important as the answer itself. While it may not get picked up easily, I think one shouldn't forget that there can be killing two birds with one stone in the case of asking some technical questions. If someone is given a whiteboard problem then various communication skills get tested, how well does the person ask questions to clarify what is the top priority in a solution, how well can he or she articulate why his or her solution is good.

Some cautions on these questions that I don't know if you'd catch this or not as there are different interpretations one could take here:

  • Do they have a general love for programming and a continual interest in improving their skills?

This can get ugly fast as I'm not sure everyone would be all excited about programming in Assembly if their job would be doing web development using rather high level languages most of the time. That "general" can be taken in many ways that aren't so great to my mind.

  • Are they willing to learn new skills?

Do you mean for this to be so open-ended? I don't think I'd want to learn how to skydive or perform open heart surgery among many other things which probably wasn't what you'd thought of in asking the question. Who wants to learn how to clean up all kinds of different chemical spills or survive a nuclear meltdown? How appropriate are those skills is a valid concern here, especially if this learning is on company time or money.

  • Are they willing to take the time to share their knowledge with and help others?

This is where excesses can be brutal. Some people could have a hard time saying no and thus their work doesn't get done because someone asked and to say no here would imply a no to this general question or was it meant to be a "most of the time but not the expense of making your own deadlines" which is what most people have as a great challenge?

  • Do they have a track record of success?

Who is defining "success" here? Does my existence to this point in time qualify as a success? Does the fact that I got to an interview location at the right time with appropriate clothing count as a success? Does it take a Herculean effort to make something a success?

  • Will the interviewee enjoy the type of work the company is doing and be dedicated to it?

How well could a company explain what that work is and be correct in allocating various %s to how much is in each category.

  • Did they work on similar projects or for similar companies before and enjoy them?

How much of the current company can be disclosed to do this properly?

  • Will they like the company's culture?

Again, there is quite likely to be multiple cultures as the company could have one, the department has another and the team carries yet another as each level may be run differently and so this isn't really a good question if the team's culture is wildly different from the company as a whole.

  • Are they committed to seeing projects succeed?

How committed are you wanting here? The kind of person that will put in 100+ hours and call in all the favors with all the friends to get meet a deadline, practically jeopardizing many people's health in the process? Think about how far do you want this and what if this person gets a little over zealous and wants others to go just as far?

In summary, you could look at these questions that may be useful for you just as background:

3
  • 1
    Questions like this SHOULD be open-ended. It allows the person to demonstrate their ability to understand communication in context. This is an essential skill. If someone fumbles on "Are you open to learning new skills" because they thought I was asking if they could learn to skydive, I would be pretty worried that the candidate lacks the social intelligence to perform well.
    – user3792
    Commented Oct 13, 2011 at 17:29
  • You make some great points. I added a comment to clarify these questions on the original post, as the intent was for these to be examples of qualities to assess not necessarily specific interview questions.
    – Cliff
    Commented Oct 13, 2011 at 17:54
  • Some programmers may take things too literally is the caution I'd want to re-iterate.
    – JB King
    Commented Oct 13, 2011 at 22:04
0

Both categories are important. I think it's also important to include technical questions that go beyond knowledge of programming languages, algorithms, data structures, and other CS concepts. Ask about:

  • Security (cross-site scripting, SQL injection, hashing passwords, symmetric vs. public/private key encryption, etc.)
  • Object-oriented design (SOLID, design patterns, etc.)
  • Unit testing, test-driven/behavior-driven development, experience with testing/mocking frameworks
  • Advantages of Continuous Integration, version control, etc., experience with such tools
  • Software development methodologies, i.e., what makes a process agile vs. waterfall, etc. Just the general ideas and flow. In fact, being able to explain things in their own terms is better than just regurgitating the Scrum guide.
  • When/what should you re-factor, what is technical debt, etc.
-1

Should interviews for programming positions be CS knowledge focused or behavioral focused?

Let's replace programming with software development. And now I'm gonna say something really crazy here: Interviews for software development positions should be focused on software development.

When looking for experienced software developers, you're look for people who understand the following:

  • Make it work!
    I wouldn't expect a software developer to be able to implement any data structure on the spot (granted, if they can't implement a linked list, then odds are low they're any good at programming). What I do expect is, that given a problem they will be able to provide a clean solution using implementations from any library they fancy. I expect them to be able to explain their choices, to show potential bottlenecks and propose improvements for scalability as required. I want to see adequate use of complex and simple data structures.
  • Does "shoulders of giants" ring a bell?
    Generally a software developer should be able to piece together solutions quickly through reuse of available libraries, unless an own implementation has verifiable benefits. In almost all cases there's no point in reinventing the wheel when writing production code. Instead I expect them to have a great ability to read other's code, study 3d party APIs and grasp new approaches. Knowing the ecosystem they will move within inside out is a plus.
  • Algorithms are eternal. Software has life cycles.
    Software developers should be able to solve completely different problems than those CS poses. CS poses well defined, isolated, small problems with verifiable constraints for the solutions. For starters, software developers must in fact develop the metrics to actually measure the quality of their solution (there's a lot of developers underestimating this and the result is horrible). Only to tackle problems, that are complex, blurry, depending on a context, which -to augment the fun- is changing over time and they need to design systems that can respond to changes. However they should:
  • Solve the given problem. Nothing less, nothing more.
    You can't have software developers write a whole new framework and develop a new branch of CS around it to solve their problems. By the time their code finally builds the first time, the requirements have changed already. A lot of code is produced in the name of reusability which isn't even usable in the first place.

I wouldn't class this under behavior. I think it's about mastery, which is at the end of path everybody has to pave with their own experience.

So figure out how far along they are on their path. How much the developer they are longing to be is the developer you need. Talk about:

  • What it is they seek in professional software development.
  • What it is they seek in personal software development.
  • Problems they have encountered, that they have been unable to solve for a long time or even until now
  • Problems they have overcome and solutions they have tailored, that they are proud of
  • ...

Of course there's a non-technical aspect to the job. Team work, knowledge exchange, mentoring, and so forth. But they are both beyond the scope of a technical interview and this site.

Please also understand, that filtering out candidates that have a basic understanding of programming and CS can easily be done prior to interviews and therefore should be done, to save valuable time, that you can use on the candidates that pass the filter, and that those who fail can use on choosing the next step for their improvement.

Not the answer you're looking for? Browse other questions tagged or ask your own question.