I work at a company that does a lot of pair programming in interviews and have been on both sides of this equation (several times as the interviewer).
When I am pair-programming with a potential hire, I am watching for two things:
1) Thought process. What happens if you encounter a bug? What if you don't know something? I have seen good and bad reactions to both of these situations. The worst reactions I tend to see are giving up, or trying changes at random until the code runs without understanding why. Some good reactions are along the lines of carefully using debugging tools, reasoning about the code, looking up documentation online, or asking their pair for input. In general I'm looking for signs that the candidate is reasoning their way along rather than flailing.
2) How you interact with me as a pair. Sometimes the person I am interviewing just wants to rabbit-hole on the problem and pretend I'm not there. That's not an automatic fault or an end to the interview or anything like that, especially if they're zipping along without issues. I understand that some people probably assume that the pair is just there to scrutinize them. But especially if they are getting stuck, I like to see that they are interacting and recognize that in addition to being an interviewer that I'm also a resource they can utilize. There are bonus points for people who explain their thought process as they're going along and really try to work with me as a pair and this can make the difference when we might otherwise be on the fence about a candidate based on technical ability alone.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I work at a company that does a lot of pair programming in interviews and have been on both sides of this equation (several times as the interviewer).
When I am pair-programming with a potential hire, I am watching for two things:
1) Thought process. What happens if you encounter a bug? What if you don't know something? I have seen good and bad reactions to both of these situations. The worst reactions I tend to see are giving up, or trying changes at random until the code runs without understanding why. Some good reactions are along the lines of carefully using debugging tools, reasoning about the code, looking up documentation online, or asking their pair for input. In general I'm looking for signs that the candidate is reasoning their way along rather than flailing.
2) How you interact with me as a pair. Sometimes the person I am interviewing just wants to rabbit-hole on the problem and pretend I'm not there. That's not an automatic fault or an end to the interview or anything like that, especially if they're zipping along without issues. I understand that some people probably assume that the pair is just there to scrutinize them. But especially if they are getting stuck, I like to see that they are interacting and recognize that in addition to being an interviewer that I'm also a resource they can utilize. There are bonus points for people who explain their thought process as they're going along and really try to work with me as a pair and this can make the difference when we might otherwise be on the fence about a candidate based on technical ability alone.