Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback on "Pair Programming Interviews" Post #1

benjmin-r opened this issue May 4, 2017 · 0 comments

Feedback on "Pair Programming Interviews" Post #1

benjmin-r opened this issue May 4, 2017 · 0 comments


Copy link

@benjmin-r benjmin-r commented May 4, 2017

As "hoped for" on Twitter, here is my feedback on this draft (aka a specific version, not the latest version of the draft).

This feedback is a mixture of a braindump, what I consider important on this topic and my thoughts, as well as my opinion or questions about the specific points already mentioned in the post.


  • IMO it's super important to let the interviewee use the keyboard 95% of the time. So, basically like an ideal driver/navigator pairing setup. The interviewer should ideally only use the keyboard to demonstrate tool usage.

  • Also very important: Make the interviewer write down their observations directly after the interviewee leaves. THIS IS IMPORTANT if you're really serious about reducing bias.
    As Dave put it in his post "Bias"

    In a nutshell, the participants were redefining “merit” based on their own biases and expectations.


    The more objective you believe yourself to be, the less objective you probably are.

  • Again, improtant: Make the expectations the hiring team and esp. the hiring manager have towards the interviewer explicit. To put this bluntly: You, as an interviewer, by way of your feedback, have the power to not hire a person. The hiring team and hiring manager must set the boundaries within which this power can be used.

Feedback on already existing draft

quotes from here on, are quotes directly from the draft

Managing expectations about what we should achieve

I also think it's important, esp. wrt reducing possibly anxiety and/or stress of the candidates, to be very explicit about the interviewer's/company's expectation towards the interviewee. What amount of time should the person plan for? What prep should the interviewee do before the pairing session? Should they read up on some stuff? Should they already possess some specific skills or know about some specific technology?
I think it's very important to answer (at least) those, even or more so if the answer to most of those is 'no' or 'not required'.

Furthermore, in the past I found it important to state in advance, what kind of coding "style" was expected in the interview. Is it expected that the candidate shows their best/cleanest possible code? Or something else? Should they obsess over naming, more than they would usually do?

Do not Pair-Programm with a candidate if you're not coding on the project in your day-to-day

I don't see why this is a relevant aspect. If you want to keep it, IMO you'd
need to give concrete reasons, why this is important.

If you want, feel free to bring your own laptop with the dev setup you are comfortable with.

I find this eventually hard to do right and would drop it. If you want to stick to this, then make it very clear, what should be installed on the interviewee's machine, which version of language runtimes, and the steps you will need to perform on-site in order to get the codebase which you want to pair on up & running. Again, even if it the project setup is really just a git clone && npm i && npm start, stating this in advance and testing it on a clean laptop in advance, can save a lot of stress and frustration.
I think a helpful way to think about this pairing session, is to prepare it like you would prepare a live coding session in front of a conference audience.

Find out how the candidate works with problems

Be sure to not be hand-waivy about this in the final post. This is very hard to
define and get right. Yet, I believe a team/company that takes the time to
define for themselves, which mode of problem solving they are looking for (be it
multiple ones), ends up hiring the people that are better suited.

Cate provides some good hints, in her posts "How I interview" and "12 Steps to being a better interviewer".

Culture Fit (unless you really want to, which I discourage you to want)

I suggest reading 'Why Hiring for "Culture Fit" Hurts Your Culture'

Other from the word 'culture fit' I would question the usefulness of this not-goal. Can you really not assess if someone "feels right". And if I put it this way, I think this not-goal is nearly the same as "See how chemistry works out" which you state as a goal above.

So, I'd scrap this from the list completely.

And while we're at it, here's my reading list for hiring practices, not
necessarily, about interviewing, and some are about onboarding (yes, there's a
good reason there are so many posts from Cate on this list. She's amayingly insightful):

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants