How to interview a former superior?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
72
down vote

favorite
5












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?







share|improve this question














migrated from programmers.stackexchange.com Apr 14 '15 at 13:18


This question came from our site for professionals, academics, and students working within the systems development life cycle.










  • 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
    Apr 14 '15 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
    Jan 6 '16 at 7:03
















up vote
72
down vote

favorite
5












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?







share|improve this question














migrated from programmers.stackexchange.com Apr 14 '15 at 13:18


This question came from our site for professionals, academics, and students working within the systems development life cycle.










  • 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
    Apr 14 '15 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
    Jan 6 '16 at 7:03












up vote
72
down vote

favorite
5









up vote
72
down vote

favorite
5






5





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?







share|improve this question














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?









share|improve this question













share|improve this question




share|improve this question








edited Sep 16 '15 at 22:50









Brian

83611320




83611320










asked Apr 14 '15 at 13:11









StronglyTyped

46344




46344




migrated from programmers.stackexchange.com Apr 14 '15 at 13:18


This question came from our site for professionals, academics, and students working within the systems development life cycle.






migrated from programmers.stackexchange.com Apr 14 '15 at 13:18


This question came from our site for professionals, academics, and students working within the systems development life cycle.









  • 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
    Apr 14 '15 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
    Jan 6 '16 at 7:03












  • 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
    Apr 14 '15 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
    Jan 6 '16 at 7:03







11




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
Apr 14 '15 at 14:05




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
Apr 14 '15 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
Jan 6 '16 at 7:03




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
Jan 6 '16 at 7:03










7 Answers
7






active

oldest

votes

















up vote
107
down vote



accepted










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.






share|improve this answer
















  • 20




    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
    Apr 14 '15 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
    Apr 15 '15 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'.
    Apr 15 '15 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
    Apr 15 '15 at 15:35










  • 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
    May 19 '17 at 23:47

















up vote
35
down vote













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).






share|improve this answer






















  • 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.
    – rm-
    Apr 15 '15 at 6:24

















up vote
16
down vote













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.






share|improve this answer


















  • 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
    Apr 14 '15 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
    Apr 14 '15 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
    Apr 14 '15 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?
    – user568458
    Apr 14 '15 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.
    – Dukeling
    Apr 14 '15 at 15:41


















up vote
7
down vote













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.






share|improve this answer



























    up vote
    0
    down vote













    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.






    share|improve this answer



























      up vote
      0
      down vote













      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.






      share|improve this answer





























        up vote
        0
        down vote













        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.






        share|improve this answer






















          Your Answer







          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "423"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          noCode: true, onDemand: false,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );








           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f44113%2fhow-to-interview-a-former-superior%23new-answer', 'question_page');

          );

          Post as a guest

























          StackExchange.ready(function ()
          $("#show-editor-button input, #show-editor-button button").click(function ()
          var showEditor = function()
          $("#show-editor-button").hide();
          $("#post-form").removeClass("dno");
          StackExchange.editor.finallyInit();
          ;

          var useFancy = $(this).data('confirm-use-fancy');
          if(useFancy == 'True')
          var popupTitle = $(this).data('confirm-fancy-title');
          var popupBody = $(this).data('confirm-fancy-body');
          var popupAccept = $(this).data('confirm-fancy-accept-button');

          $(this).loadPopup(
          url: '/post/self-answer-popup',
          loaded: function(popup)
          var pTitle = $(popup).find('h2');
          var pBody = $(popup).find('.popup-body');
          var pSubmit = $(popup).find('.popup-submit');

          pTitle.text(popupTitle);
          pBody.html(popupBody);
          pSubmit.val(popupAccept).click(showEditor);

          )
          else
          var confirmText = $(this).data('confirm-text');
          if (confirmText ? confirm(confirmText) : true)
          showEditor();


          );
          );






          7 Answers
          7






          active

          oldest

          votes








          7 Answers
          7






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          107
          down vote



          accepted










          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.






          share|improve this answer
















          • 20




            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
            Apr 14 '15 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
            Apr 15 '15 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'.
            Apr 15 '15 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
            Apr 15 '15 at 15:35










          • 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
            May 19 '17 at 23:47














          up vote
          107
          down vote



          accepted










          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.






          share|improve this answer
















          • 20




            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
            Apr 14 '15 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
            Apr 15 '15 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'.
            Apr 15 '15 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
            Apr 15 '15 at 15:35










          • 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
            May 19 '17 at 23:47












          up vote
          107
          down vote



          accepted







          up vote
          107
          down vote



          accepted






          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.






          share|improve this answer












          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Apr 14 '15 at 14:13









          Kent A.

          19.2k75575




          19.2k75575







          • 20




            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
            Apr 14 '15 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
            Apr 15 '15 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'.
            Apr 15 '15 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
            Apr 15 '15 at 15:35










          • 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
            May 19 '17 at 23:47












          • 20




            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
            Apr 14 '15 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
            Apr 15 '15 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'.
            Apr 15 '15 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
            Apr 15 '15 at 15:35










          • 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
            May 19 '17 at 23:47







          20




          20




          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
          Apr 14 '15 at 16:59




          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
          Apr 14 '15 at 16:59




          7




          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
          Apr 15 '15 at 12:11




          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
          Apr 15 '15 at 12:11




          5




          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'.
          Apr 15 '15 at 13:02




          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'.
          Apr 15 '15 at 13:02




          6




          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
          Apr 15 '15 at 15:35




          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
          Apr 15 '15 at 15:35












          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
          May 19 '17 at 23:47




          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
          May 19 '17 at 23:47












          up vote
          35
          down vote













          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).






          share|improve this answer






















          • 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.
            – rm-
            Apr 15 '15 at 6:24














          up vote
          35
          down vote













          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).






          share|improve this answer






















          • 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.
            – rm-
            Apr 15 '15 at 6:24












          up vote
          35
          down vote










          up vote
          35
          down vote









          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).






          share|improve this answer














          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).







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Apr 14 '15 at 17:34









          TRiG

          155214




          155214










          answered Apr 14 '15 at 14:08









          Cronax

          7,69432235




          7,69432235











          • 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.
            – rm-
            Apr 15 '15 at 6:24
















          • 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.
            – rm-
            Apr 15 '15 at 6:24















          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.
          – rm-
          Apr 15 '15 at 6:24




          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.
          – rm-
          Apr 15 '15 at 6:24










          up vote
          16
          down vote













          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.






          share|improve this answer


















          • 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
            Apr 14 '15 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
            Apr 14 '15 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
            Apr 14 '15 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?
            – user568458
            Apr 14 '15 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.
            – Dukeling
            Apr 14 '15 at 15:41















          up vote
          16
          down vote













          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.






          share|improve this answer


















          • 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
            Apr 14 '15 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
            Apr 14 '15 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
            Apr 14 '15 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?
            – user568458
            Apr 14 '15 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.
            – Dukeling
            Apr 14 '15 at 15:41













          up vote
          16
          down vote










          up vote
          16
          down vote









          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.






          share|improve this answer














          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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Apr 15 '15 at 13:41

























          answered Apr 14 '15 at 13:50









          Vietnhi Phuvan

          68.9k7118254




          68.9k7118254







          • 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
            Apr 14 '15 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
            Apr 14 '15 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
            Apr 14 '15 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?
            – user568458
            Apr 14 '15 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.
            – Dukeling
            Apr 14 '15 at 15:41













          • 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
            Apr 14 '15 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
            Apr 14 '15 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
            Apr 14 '15 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?
            – user568458
            Apr 14 '15 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.
            – Dukeling
            Apr 14 '15 at 15:41








          23




          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
          Apr 14 '15 at 14:37




          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
          Apr 14 '15 at 14:37




          4




          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
          Apr 14 '15 at 15:05




          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
          Apr 14 '15 at 15:05




          4




          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
          Apr 14 '15 at 15:40





          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
          Apr 14 '15 at 15:40





          4




          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?
          – user568458
          Apr 14 '15 at 15:40




          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?
          – user568458
          Apr 14 '15 at 15:40




          1




          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.
          – Dukeling
          Apr 14 '15 at 15:41





          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.
          – Dukeling
          Apr 14 '15 at 15:41











          up vote
          7
          down vote













          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.






          share|improve this answer
























            up vote
            7
            down vote













            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.






            share|improve this answer






















              up vote
              7
              down vote










              up vote
              7
              down vote









              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.






              share|improve this answer












              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.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Apr 14 '15 at 13:50









              scriptin

              1705




              1705




















                  up vote
                  0
                  down vote













                  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.






                  share|improve this answer
























                    up vote
                    0
                    down vote













                    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.






                    share|improve this answer






















                      up vote
                      0
                      down vote










                      up vote
                      0
                      down vote









                      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.






                      share|improve this answer












                      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.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Apr 15 '15 at 8:27









                      Benjamin Gruenbaum

                      3,69921929




                      3,69921929




















                          up vote
                          0
                          down vote













                          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.






                          share|improve this answer


























                            up vote
                            0
                            down vote













                            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.






                            share|improve this answer
























                              up vote
                              0
                              down vote










                              up vote
                              0
                              down vote









                              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.






                              share|improve this answer














                              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.







                              share|improve this answer














                              share|improve this answer



                              share|improve this answer








                              edited Apr 15 '15 at 8:36

























                              answered Apr 15 '15 at 8:22









                              Level River St

                              1,393510




                              1,393510




















                                  up vote
                                  0
                                  down vote













                                  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.






                                  share|improve this answer


























                                    up vote
                                    0
                                    down vote













                                    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.






                                    share|improve this answer
























                                      up vote
                                      0
                                      down vote










                                      up vote
                                      0
                                      down vote









                                      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.






                                      share|improve this answer














                                      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.







                                      share|improve this answer














                                      share|improve this answer



                                      share|improve this answer








                                      edited Feb 22 '17 at 8:03

























                                      answered Feb 22 '17 at 7:48









                                      Honza Zidek

                                      1093




                                      1093






















                                           

                                          draft saved


                                          draft discarded


























                                           


                                          draft saved


                                          draft discarded














                                          StackExchange.ready(
                                          function ()
                                          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f44113%2fhow-to-interview-a-former-superior%23new-answer', 'question_page');

                                          );

                                          Post as a guest

















































































                                          Comments

                                          Popular posts from this blog

                                          What does second last employer means? [closed]

                                          Installing NextGIS Connect into QGIS 3?

                                          One-line joke