5 ms·

I am still floored that pair programming hasn't become the standard for interviews. Get a simple kata or problem - that the interviewer AND interviewee haven't

I am still floored that pair programming hasn't become the standard for interviews. Get a simple kata or problem - that the interviewer AND interviewee haven't seen before. Set up a "code with me" session. Pair program. See what happens in two pomodoro - have a chat in-between. Swap roles. 1) Do you see tests? 2) Do the tests pass? 3) Did anyone lose their cool? 4) Does the code look good? Have a score - keep the scores of all interviews (anonymize them of course) - and as you go along see where a candidate fits on the curve. The problems have to fit into two pomodoros - you have to try this against one of your junior devs and a lead to verify.

arp242 4y ago
I can't pair program, especially not in an interview setting. Being watched makes me so nervous that I can't think straight, unless it's someone I know well. I also can't think and talk at the same time, and someone talking to me makes me lose my entire train of thought. I don't think I'm the only one.
- mywittyname 4y ago
  You're not the only one. I will say that comfort often comes with practice. I do pair programming sessions with people as part of my job. This has made me a substantially better at pair programming as part of interviewing (on both sides). Perhaps it would be worthwhile for you to time to work with some colleagues to build some of these muscles. I do agree that alternatives should be offered if someone is uncomfortable.
- edgyquant 4y ago
  Then you are not gonna do well in any interview or team setting; which basically disqualifies you from working in this field unless it’s open source or something.
  - cloverich 4y ago
    Pair programming is quite rare in most orgs. Most code is discussed async after its been written. A take home test where you modify some existing code based on new business requirements would be far more similar to the real job. LIVE Discussion about the requirements before or code after would also be similar.
    - edgyquant 4y ago
      Most interviews involve either pair programming or whiteboard problems. Not being able to think when being watched is not gonna cut it.
      - erik_seaberg 4y ago
        Interviewers all seem to state the problem and then let me work quietly between a few clarifying questions. My impression of pairing is a lot more talking with no time to start thinking.
  - s__s 4y ago
    What on earth are you talking about? I’ve been in the industry a really long time and have never seen anyone actually pair program. The entire concept of pair programming is silly. If anything it’s ear phones on and don’t bug me.
  - arp242 4y ago
    That's ridiculous; only once has this been asked during an interview.
- bradlys 4y ago
  I'm going to guess you can't do leetcode then either because it's essentially pair programming - minus the part where you're working together.
  - arp242 4y ago
    I don't think it's the same at all, because people aren't watching every character you type, including the mistakes. My mother told me I spoke very little as a child, but in the evening she could hear me practising words outside my bedroom door. I suppose this is some deeply seated neuroticism.
agentwiggles 4y ago
This is very close to what our company does, and I think it's a great process. We like to give a two part problem - something relatively simple like an "early-December" Advent of Code problem. We give the first portion as a take-home project, then do a pairing style interview, where we spend a little bit of time discussing the solution, and then pair on the second part. We see how the candidate approaches problems from their initial solution, and then we get to see how they react to being asked to extend things. We get to talk to them about how easy their code is to change, how their tests helped support the changes. We get to see them work through a problem under slight pressure, and hear them communicate with a partner about the problem. As an example of the level of problem we're looking at, here's an AoC problem we've used before: https://adventofcode.com/2021/day/2 https://adventofcode.com/2021/day/2. A couple of notes: * We keep the problem easy like the one above because we're not trying to see if a person is a genius or has memorized a lot of algorithms. We just want to get a basic pulse on their skill level. For a junior dev, this kind of problem is doable but might take a little while. For a senior, this should be basically trivial. * When I mention that a candidate is under some pressure, I don't mean that we add any artificial pressure - that would be dickish. I just mean that interviews are naturally a bit of a high-pressure situation, so we get to see if they keep their cool, etc. * The candidate drives, but we try to approach the problem as a real pairing situation, so the candidate should talk through ideas with the interviewers, the interviewers can and should _actually help_ solve the problem, etc. * The "take-home" portion is designed with the intent of not taking up more than an hour or so of the candidate's time, and is really there just to give us a starting point to talk about. It also ensures that the candidate has a project set up and ready to go for the interview in the language of their choice, which eliminates a lot of churn from the beginning of the interview. I helped design the process so I'm biased, but I think it's extremely effective.
stcroixx 4y ago
I would hate that and do terrible myself. I need to focus to do my best and having another person around to interact with would be a huge distraction. Plus in 25 years of working on software I've never produced anything of value working that way.
guenthert 4y ago
Hell no. If I could possibly smell whether you had a shower this morning, you are too close. I'm not going to share a keyboard, terminals are cheap and have been for a long time. This is a cultural thing. Don't expect me to become a new person to fit into your work flow. Now I know that buddies of mine did great work like that as teenagers creating games (and some sold reasonably well), so yes this can work beautifully. Thing is just, you're not my buddy and I'm no teenager any more.
- sixstringtheory 4y ago
  Remote pair programming has been possible for a long time now.
konschubert 4y ago
It is A LOT of effort to have a problem that the interview hasn't seen but that's also been tested with a junior and a lead. Most companies aren't willing to invest these kind of resources into the preparation of each interview.
- jgerrish 4y ago
  I participated in a paired programming interview once. I didn't get the job, but I walked away with respect for the organization doing it. It gave them a chance to see how I worked as part of a team. Even if day to day I'm not pair programming, it starts off the relationship saying "If you need help on a problem, you can be comfortable working with your teammates." The great thing about the setup is that it doesn't have to be a unique or complex problem. "Write a function to reverse a string. We'll write unit tests in parallel with that." Or one of the thousand other problems. You're not testing algorithms here, you're testing whether the candidate is arrogant. Or talks too much. Or doesn't ask for help. What happens when they get stuck? You're right, it's a lot of effort. But the resources spent on a bad hire can be even more expensive.
lannisterstark 4y ago
Nah, fuck that. Give me a code problem any day, and stop asking me to pair with someone else.

arp242 4y ago

I can't pair program, especially not in an interview setting. Being watched makes me so nervous that I can't think straight, unless it's someone I know well. I also can't think and talk at the same time, and someone talking to me makes me lose my entire train of thought. I don't think I'm the only one.

mywittyname 4y ago
You're not the only one. I will say that comfort often comes with practice. I do pair programming sessions with people as part of my job. This has made me a substantially better at pair programming as part of interviewing (on both sides). Perhaps it would be worthwhile for you to time to work with some colleagues to build some of these muscles. I do agree that alternatives should be offered if someone is uncomfortable.
edgyquant 4y ago
Then you are not gonna do well in any interview or team setting; which basically disqualifies you from working in this field unless it’s open source or something.
- cloverich 4y ago
  Pair programming is quite rare in most orgs. Most code is discussed async after its been written. A take home test where you modify some existing code based on new business requirements would be far more similar to the real job. LIVE Discussion about the requirements before or code after would also be similar.
  - edgyquant 4y ago
    Most interviews involve either pair programming or whiteboard problems. Not being able to think when being watched is not gonna cut it.
    - erik_seaberg 4y ago
      Interviewers all seem to state the problem and then let me work quietly between a few clarifying questions. My impression of pairing is a lot more talking with no time to start thinking.
- s__s 4y ago
  What on earth are you talking about? I’ve been in the industry a really long time and have never seen anyone actually pair program. The entire concept of pair programming is silly. If anything it’s ear phones on and don’t bug me.
- arp242 4y ago
  That's ridiculous; only once has this been asked during an interview.
bradlys 4y ago
I'm going to guess you can't do leetcode then either because it's essentially pair programming - minus the part where you're working together.
- arp242 4y ago
  I don't think it's the same at all, because people aren't watching every character you type, including the mistakes. My mother told me I spoke very little as a child, but in the evening she could hear me practising words outside my bedroom door. I suppose this is some deeply seated neuroticism.

agentwiggles 4y ago

This is very close to what our company does, and I think it's a great process. We like to give a two part problem - something relatively simple like an "early-December" Advent of Code problem. We give the first portion as a take-home project, then do a pairing style interview, where we spend a little bit of time discussing the solution, and then pair on the second part. We see how the candidate approaches problems from their initial solution, and then we get to see how they react to being asked to extend things. We get to talk to them about how easy their code is to change, how their tests helped support the changes. We get to see them work through a problem under slight pressure, and hear them communicate with a partner about the problem. As an example of the level of problem we're looking at, here's an AoC problem we've used before: https://adventofcode.com/2021/day/2 https://adventofcode.com/2021/day/2. A couple of notes: * We keep the problem easy like the one above because we're not trying to see if a person is a genius or has memorized a lot of algorithms. We just want to get a basic pulse on their skill level. For a junior dev, this kind of problem is doable but might take a little while. For a senior, this should be basically trivial. * When I mention that a candidate is under some pressure, I don't mean that we add any artificial pressure - that would be dickish. I just mean that interviews are naturally a bit of a high-pressure situation, so we get to see if they keep their cool, etc. * The candidate drives, but we try to approach the problem as a real pairing situation, so the candidate should talk through ideas with the interviewers, the interviewers can and should _actually help_ solve the problem, etc. * The "take-home" portion is designed with the intent of not taking up more than an hour or so of the candidate's time, and is really there just to give us a starting point to talk about. It also ensures that the candidate has a project set up and ready to go for the interview in the language of their choice, which eliminates a lot of churn from the beginning of the interview. I helped design the process so I'm biased, but I think it's extremely effective.

stcroixx 4y ago

I would hate that and do terrible myself. I need to focus to do my best and having another person around to interact with would be a huge distraction. Plus in 25 years of working on software I've never produced anything of value working that way.

guenthert 4y ago

Hell no. If I could possibly smell whether you had a shower this morning, you are too close. I'm not going to share a keyboard, terminals are cheap and have been for a long time. This is a cultural thing. Don't expect me to become a new person to fit into your work flow. Now I know that buddies of mine did great work like that as teenagers creating games (and some sold reasonably well), so yes this can work beautifully. Thing is just, you're not my buddy and I'm no teenager any more.

sixstringtheory 4y ago
Remote pair programming has been possible for a long time now.

konschubert 4y ago

It is A LOT of effort to have a problem that the interview hasn't seen but that's also been tested with a junior and a lead. Most companies aren't willing to invest these kind of resources into the preparation of each interview.

jgerrish 4y ago
I participated in a paired programming interview once. I didn't get the job, but I walked away with respect for the organization doing it. It gave them a chance to see how I worked as part of a team. Even if day to day I'm not pair programming, it starts off the relationship saying "If you need help on a problem, you can be comfortable working with your teammates." The great thing about the setup is that it doesn't have to be a unique or complex problem. "Write a function to reverse a string. We'll write unit tests in parallel with that." Or one of the thousand other problems. You're not testing algorithms here, you're testing whether the candidate is arrogant. Or talks too much. Or doesn't ask for help. What happens when they get stuck? You're right, it's a lot of effort. But the resources spent on a bad hire can be even more expensive.

lannisterstark 4y ago

Nah, fuck that. Give me a code problem any day, and stop asking me to pair with someone else.