73

I'm a programmer who's now in a management position, and I've recently gained a fair amount of experience interviewing programmers. I feel very comfortable with the interview process and conduct my interviews as follows:

  • Programming quiz where the candidate hand-writes code.
  • General questions (personality, problem solving, situational).
  • "Whiteboard" type discussion about a hypothetical project assignment.

This process has worked very well so far, but I don't feel it would make sense to use for an upcoming interview I have with a former superior. I worked with him when I was a junior programmer and he was a senior programmer. I left to work for a different company, and we both moved into management positions, and now he's transitioning back to a senior programming role. He is older and more experienced than I am, and I'm unsure how to conduct a productive interview.

One idea I had was to re-gear the whiteboard discussion to put more emphasis on teamwork and conflict resolution and less on skill set evaluation, but overall, for the rest of the interview, I'm really struggling to identify what I should objectively be looking for. Since he was a former mentor of mine, I'm finding it difficult to remove myself from the situation and look at it objectively.

Can anyone offer advice for the following:

  • What the main points of focus for evaluation should be.
  • What "red flags" I should be looking for.
  • Is there a way to give a programming quiz without being insulting?
  • Should I even be concerned with a technical/skill set evaluation?
  • What are some useful questions I can ask to learn if he would mesh well with our team?

To anyone who has been through this before, can you share your hindsight thoughts?

Improve this question
2
  • 11
    Are you the only one doing the interview or will there be others present? Maybe you're familiar with your former colleagues abilities, but maybe the others present on your side don't have that advantage
    – Brandin
    Commented Apr 14, 2015 at 14:05
  • Did you work together in your current company or in an earlier employment? If this company has never heard of the person before, there is nothing insulting in following protocol and giving him a quiz and anything else you would give any other application because your current employer needs to know.
    – Thorbjørn Ravn Andersen
    Commented Jan 6, 2016 at 7:03

7 Answers 7

Reset to default
114

In this case, you really should consider whether you are the right person to interview the candidate. You really should let someone else interview him (who is qualified to interview), and you can be a "character witness." At the very least, you should have at least one other interviewer with you. The risk of being unduly biased (one way or the other) is too great.

You should not deviate too much from your routine of interviewing, especially if your company has interviewing guidelines/standards.

Improve this answer
6
  • 21
    This has been standard practice pretty much everywhere I've worked. People who have overlapping work experience recuse themselves from interviews. Recommendations are welcome, even encouraged and can carry a lot of weight, but objectivity is key for interviewing. This just avoids so many potential problems, whatever your actual opinion of the candidate might be.
    – Dacio
    Commented Apr 14, 2015 at 16:59
  • 7
    So much this. If you conduct this interview and then someone later finds out that you knew the guy beforehand they might assume he got the job cause you had known each other, causing unnecessary problems for you and him. This is what is considered a conflict of interest and you should make this situation as transparent as you can to YOUR management (provided there are people supervising you).
    – Ceiling Gecko
    Commented Apr 15, 2015 at 12:11
  • 5
    I'd stress out more the fact that it doesn't matter if you manage to be objective, what matters is what other people will perceive. If they think you might have been biased, even if you weren't, you will be in trouble.
    – o0'.
    Commented Apr 15, 2015 at 13:02
  • 6
    tbh if you can't treat a former superior as a subordinate in this interview, and they can't deal with it too, how do you expect it to work in the job itself? This is the ideal test.
    – JamesRyan
    Commented Apr 15, 2015 at 15:35
  • 1
    I won't argue against having another interviewer being present, but we (professional society?) really need to rethink what we mean by bias and objectivity. For goodness sake, the point of the interview process is to BECOME BIASED for one candidate so that a clear decision can be made. Even as a "character witness" on the side, the effect is that this person definitely biases the process and should not be afraid to do so. Imagine the ridiculous irony when asking for character references... just to have already eliminated an existing employee who could provide that as good as any other.
    – C Perkins
    Commented May 19, 2017 at 23:47
35

Although you already know this person, straying too much from your normal interviewing routine will evidently make things harder on you. As you are the interviewer, you get to dictate how to handle the interview. As such, I would simply conduct my normal routine interview after saying something along the lines of:

Hey X, welcome to company Y, I know we've worked together before but in order to ensure objectivity, for the purpose of this interview I'd like us to pretend we've never met before. Would that work for you?

During the interview, try to put your preconceptions aside. Time has passed since you last worked together, so you need to assess the current skill level of your former superior. They may have taught you all you know, but if they haven't kept up with the developments since then they may not be a good fit for your team. Ask all the questions you normally would, even if you already know the answer. If the candidate ever responds dismissively, this is a red flag that they may not be able to see you as their superior, which could lead to problems in the team down the line.

If you really find yourself unable to do this, try to get someone else to join you in interviewing this person or even withdraw from this interview altogether. You're trying to ensure that the candidate gets a fair chance at an objective judgement and if you find yourself unable to do this then you will doing none of the involved parties any favours (you yourself, your former superior and your company).

Improve this answer
1
  • I think this is the most valuable comment and the best way to conduct such an interview. What I'd add is that the results of an interview are often shared among hiring managers and recruiters, so the basic idea is to stick to already defined interview process as much as possible. I had the negative experience about this (passed a former teammate without asking typical questions and then forwarding answers to HR database), being too far from the process can definitely cause problem in future.
    – rishat
    Commented Apr 15, 2015 at 6:24
16

You know he is competent so you can spare him the trivia quiz. However,what you give with one hand, you take with the other hand. This is what I would focus on:

  1. Is his coding style compatible with the organization's? If not, can he adapt it to the organization's?

  2. Are his coding techniques up to date? You don't want him populating your code base with obsolete techniques

  3. Was he an effective mentor to you? If mentoring is part of the job description, is he still willing to mentor others?

  4. Does he have what it takes to be a team lead in your organization? A team lead would operate on the premise that the software engineering process - think implementation of continuous integration/continuous deployment at team scale -is at least as important as the code architecture and the coding style aspects. Do you like the way he architects the code e.g. how he organizes the code into modules and libraries? Is he expected to know how to write code that scales? Does he excel at writing clean, well documented code?

  5. How do you like him as a problem solver? My own ingenuity can be fiendish, and I have occasionally outsmarted myself :)

  6. Does he work well with you? Do you expect him to work well with others? If there is one kind of colleague I don't like, it's the colleagues who change code without telling anyone.

  7. What is his idea of best software engineering practices? After having worked all these years, he should have an opinion.

@JoelEtherton and @msouth among others have expressed the concern that everyone is treated the same and consistently. My attitude is that if a set of concerns is taken care of, another set of concern goes to the front burner. If, by say looking at someone's github, I am satisfied as to someone's basic competence, I am not going to spend much of any time on the typing tests. Because I have concerns that are now more urgent that I need to attend to.

Improve this answer
7
  • 23
    I don't know that I can agree with this: You know he is competent so you can spare him the trivia quiz. Depending on the environment, it may be prudent to document any/all HR proceedings. To avoid the appearance of favoritism or "occupational nepotism", it would be a good idea to go through the entire interview with that goal in mind. Whether OP cares about the answers is irrelevant in the end, but documenting it may not be.
    – Joel Etherton
    Commented Apr 14, 2015 at 14:37
  • 4
    I upvoted this answer, but I agree with @JoelEtherton 's concern here. You can let him know that you need to do this because it's part of the process if you want. Or just do it like you do with everyone else.
    – msouth
    Commented Apr 14, 2015 at 15:05
  • 4
    As important as ticking the boxes for HR, you should tick them for yourself. Your recollection is that he was competent back then. Time has passed. You're no longer a junior so you might have higher standards. He's been doing something else and is seeking to return to being a senior programmer, so he might be off his past performance, or he might be even better and would benefit in the interview process from proving it. You're working for a different company, so you might be emphasising different aspects of "competent" now than you were then. So, use the interview to assess him.
    – Steve Jessop
    Commented Apr 14, 2015 at 15:40
  • 4
    If there's a test, everyone should do it. Having a known person take the same quiz gives you a useful benchmark to better contextualise the others' results. Also, the asker remembers the senior being highly skilled - but that was through the eyes of a junior. Maybe they didn't notice things they'd now recognise as sloppy technique? Maybe the senior got complacent or lazy and is actually worse now than he was then?
    – user56reinstatemonica8
    Commented Apr 14, 2015 at 15:40
  • 1
    This appears to stray extremely far from the asker's current interviewing process (which, in itself, can give the appearance of favoritism, and that's not to even mention not evaluating his competence at all). While these may be good interviewing focus points in general (in addition to evaluating general programming competence), suddenly switching to these for one interview will leave the asker unable to effectively compare candidates. This, IMO, in some form, would be better as an addendum to an answer as opposed to an answer by itself.
    – Bernhard Barker
    Commented Apr 14, 2015 at 15:41
7

I used to do a something very similar to your approach. Simplest questions always came first, so I could skip some of them if it was obvious that candidate was skilled enough. Also, if it went well, I used to spend more time on "high-level" questions/discussions.

So, if you already know that your former superior have skills, you can safely skip some simpler parts of your interview and concentrate on something more complex.

What the main points of focus for evaluation should be.

It depends on a position, not person. There are requirements - just test them.

What "red flags" I should be looking for.

Again, it depends on position. I used to look for signs of "toxicity" in a person.

Is there a way to give a programming quiz without being insulting?

Programming quiz is not insulting by itself. If it insults a candidate, that is probably a red flag you're looking for. Person who is insulted by coding quiz might as well be insulted by a job assignment which is not "up to scale" with his/her "skills" (in fact, ambitions).

Should I even be concerned with a technical/skill set evaluation?

Yes, as much as position requires that type of skills. But, as I said, the amount of questions for each level of difficulty should be adjusted, otherwise you can just waste a time on trivia.

What are some useful questions I can ask to learn if he would mesh well with our team?

I don't know such questions. From my experience, it is just better to judge by your own emotions: if you like a person, you will mesh with him/her well in a team. I asked my colleagues if they liked a candidate when I could - we used to interview with two interviewers, so we had at least two opinions.

Improve this answer
1

From a technical PoV

Maybe this is the obvious answer, but since you've already evaluated his programming skills when he was your superior - if as you say his programming skills are good and he'd pass the regular interview to the point it'd make it pointless - just recommend they hire him.

Working with someone gives you a far better indication of their programming ability than interviewing them for an hour or two.

From a Legal PoV

You need to make sure there aren't any equal-opportunity issues. In some places it's illegal to give different candidates different interview types and by giving him a different interview you might be exposing your company legally. So, depending on where you are you might have to give him a very similar interview to the one you give other candidates.

Improve this answer
1

I was interviewed and offered a job at company A. I rejected it, explaining that it was because I was offered a ridiculous salary at company B. 2 years later company B moved to a different country, and I decided to stay where I was rather than go with them. I found myself back discussing a position with company A.

My interviewer/boss (I accepted the job 2nd time round) at company A called my new interview there a "meeting" rather than an interview. Because I had already performed well at the first interview 2 years previously, we did little more than discuss my salary and start date. You already know the guy a lot better than my boss at company A did. Is there any need to discuss more than that? (Maybe if you know him but HR don't, they will have some questions...)

You could certainly spend some time discussing what your organization is trying to achieve, to see if it would be a good fit for both of you.

Improve this answer
0

Excellent answers, I would just like to add one important point which was not emphasized enough: An interview is a bi-directional dialogue. It's not only you as the interviewer who asks questions! Make the interview a dialogue where both parties find out if they want to work together. You might know him, but he does not know your company and he needs to know if he wants to work with you. And you are much more valuable partner for him as he maybe trust you more than a common interviewer - and you will be probably more reluctant to repeat him the common manager bullshit on the interview because you would feel embarrassed.

So taking this into account, I would add to the answers this:

What the main points of focus for evaluation should be.

The evaluation is bi-directional, so evaluate mutually if you as organization want to work with him, and if he as an individual want to work with your organization.

What "red flags" I should be looking for.

Does the style and work culture suit him?

Is there a way to give a programming quiz without being insulting?

Just do it as you do. If he does not understand following protocol, maybe he is not compatible with your organization.

Should I even be concerned with a technical/skill set evaluation?

Of course! Maybe he has moved somewhere and does not want to do what he used to do before (like back-end -> front-end or vice versa)

What are some useful questions I can ask to learn if he would mesh well with our team?

Ask him what he wants to do.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .