I'm not saying 'you're doing it wrong' I'm just saying this shit is complex AF and adding pair programming doesn't make it rainbows
-
-
for sure. i kinda like a takehome as a first step, maybe then on to pairing. hot take, but it feels like those complement each other well
1 reply 0 retweets 0 likes -
Take-homes: 1) Should be timeboxed to < 3 hours. 2) Finite scope and complexity. 3) Code belongs to candidate (e.g. can post on GitHub).
2 replies 0 retweets 0 likes -
Pairing: 1) Should actually be pair problem solving. 2) Interviewer should drive initially. 3) Task should be simple and concrete.
1 reply 0 retweets 0 likes -
Pairing in our actual job is pair problem solving so our interviews work the same way. Interviewers drive to get candidate comfy.
1 reply 0 retweets 0 likes -
We usually try to get to a point where we calibrate what to ask of the candidate based on the comfort level as we got into the problem.
1 reply 0 retweets 0 likes -
If the candidate's breezing, ramp up a bit (& consider a higher level if hired). If not, calibrate down so candidate can still show skill.
1 reply 0 retweets 0 likes -
I also always let the candidate choose a rough area of interest (and tools) so they stay in their comfort zone.
1 reply 0 retweets 1 like -
As for stuff like test suites, since we're working on a real world problem, we use what's there. Lots of allowances for "unfamiliar context"
1 reply 0 retweets 0 likes -
For clarity, typically at the beginning I whiteboard for a few minutes to give the candidate the lay of the land, ...
1 reply 0 retweets 0 likes
... then dive into an area of the code that is relevant to the high level discussion. Setting the context for the problem helps.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.