Agree. Pairing up during the onsite follow up interview whilst you describe and extend your sample app is essential part of my recruitment preferences.
That is how I expect people to work once they are hired so I expect candidates to be comfortable with it. Many are not, including me 10 years ago. But most are these days.
I don't expect them to solve the problem perfectly during that time, or even at all. The important bit is to test how they try to solve it, and how they communicate during it. Using Dash, google, SO, etc if fine, asking for help is fine. Essentially portray how they would work if hired.
Many times this has quickly highlighted complete blaggers, or cowboys that should be rejected, or people caught like rabbit in head lights that are not right for us now (but maybe later).
Adding a requirement that completely blows most people's initial domain model is good way to see how people respond, even if the requirement is essentially impossible.
> Agree. Pairing up during the onsite follow up interview
> whilst you describe and extend your sample app is
> essential part of my recruitment preferences.
When you say "describe and extend your sample app", where does this sample app come from ? Do you give the candidate a chance to work or go through the sample app on his own for some time before you pair ?
If that is the case then yes, I guess that is probably the correct way to do it.
However of late what I have experienced in general is that I have to go in, meet up people for the very first time in my life, they give me a problem and a laptop/computer/pairing station and a written description of the problem which I get maybe five minutes to assess and understand and then... have a go at it, while the strange (sometimes grumpy) developer sits next to me. If I go quiet for 5 minutes I get the "what are you thinking ?" question and then I have to talk while I write code at the same time !
Maybe it works for some or most of the people out there.
That is how I expect people to work once they are hired so I expect candidates to be comfortable with it. Many are not, including me 10 years ago. But most are these days.
I don't expect them to solve the problem perfectly during that time, or even at all. The important bit is to test how they try to solve it, and how they communicate during it. Using Dash, google, SO, etc if fine, asking for help is fine. Essentially portray how they would work if hired.
Many times this has quickly highlighted complete blaggers, or cowboys that should be rejected, or people caught like rabbit in head lights that are not right for us now (but maybe later).
Adding a requirement that completely blows most people's initial domain model is good way to see how people respond, even if the requirement is essentially impossible.