How to prepare a technical interview (and why good programmers also fail)

Apparently this isn't limited to code for you, what an eloquent way to put it. I'm definitely stealing this, thanks! ;)

“creative”

I hear you loud and clear, I tend to be the same. But pair-programming has its uses, imho, which become more obvious as a lead tbh. One fundamental premise for me: voluntary participation only, it's usually bad to force it on people.

Briefly and imho, there are two kinds: "true pair" as equals (or close enough), and "asymmetric" (more like mentor-mentee). Let's tackle the latter first:

- To onboard a new team member, it's invaluable in helping them build confidence fast, learn the codebase, and integrate the team's standards and "best practice" — more to-the-point and pleasant than reading a bunch of docs: have a co-worker tell it to you, like it is, on-the-fly and on a need-to basis. Saves loads of time searching in the dark. Typically short-term (first few weeks).

- Transfer: it dramatically raises the operational level of the mentee. It effectively 'multiplies' the mentor's superiority, 'spreads it' throughout the team so to speak, as other people pick up the good stuff directly from the mouth of the lion(s).

This can be long term, depends on who you've got. I love when juniors are free to pair-prog with a willing senior, you get them out of the green zone in months as opposed to a year or more.

The benefit compounds over time, if you're building a team, it's really second-to-none (no bootcamp, no code review, no nothing comes even close). You do 'lose' one member for some time, few hours per week, but it's often a welcome walk in the park for the senior, and a really good time for the junior. It's everything you can never get in school, because it's ad hoc training both for the job and the company/team's culture/standards.

Now for pair-prog 'as equals'. Again, as a free association between two people who choose each other.

The idea here is that in terms of human brain you've got twice the 'RAM' (attention, memory, etc) and twice the 'CPU' (raw 'intelligence'). So it works ideally like a distributed system (not a failover/HA!) where each person focuses on different aspects. There is typically not much room for 'style' or 'creativity' insofar as it's decided before we write, through discussion. When one writes, the other should not interject for small details like “why not inlining here? why this name and not that name?” unless it's not just preference but mistakes or architecture etc (“did you know you could avoid all that and just write <some idiomatic thing>?” — or “this is correct but here's how we'd rather write it: ..., because it's more readable / idiomatic”)

The point is to share the thought process, and then have one set of eyes writing while the other thinks. It's thinking even slower, using two brains if you will, not at the same level — one, writing, is bound to think 'closer' to the code, while the other, watching, is free to roam-think around, look up some other file, specs, etc. Even write docs as we go, which may save time later (there is no 'rule', I only care for what actually works in practice and everyone's different so...) E.g. I don't like pattern-shoving but finding one is a common 'eureka' by the observer.

(I'd typically want a common 'pair' machine + both bring their own laptop, if doing this in person, so that each is free to do stuff. Sometimes we just off the pair prog to go faster (when human goes monkey because we have to).

What I find is that:

- explaining my 'plan' before anything is written helps make it clearer, and spot mistakes early on.

- others generally have half the good ideas seen in the final code.

- working with someone who knows a language/framework/whatever tool better makes me better with it; but it works both ways, as explaining/teaching also makes me better.

- as you said, some tasks are well-suited for this exercise, others not so much (it's usually obvious once we start).

And it's really that, an "exercise" more than anything else. It's slow, like 2-3x slower, but you feel very solid. I don't have numbers but I'd say easily 50-75% less mistakes in the final code, and most importantly code that's almost certainly readable by others.

It gets really good when domain knowledge is much wider, e.g. I know http server stuff, and you know microservices well... you can see where this takes us quite naturally — hence, again, free association, let people talk, get to know each other's forte and weaknesses, and work in complementarity.

Sorry for a long piece. I just found so much benefits in pair programming that I have to share this stuff. More than skill, it builds self-confidence and awareness. You're not the same after pair programming for 'some time' on a regular basis (and by 'you' I don't mean the programmer, I mean the entire person). Because you've realized everyone's just as limited and capable as you, and suddenly there are much less artificial barriers in your mind. “I can do this” — why? because you've seen others do it first hand, picked up from them, saw them do the same with you, and eventually we feel more like humans just trying our best instead of doubting our every commit.