|
|
|
|
|
|
by Ancapistani
1147 days ago
|
|
|
I've been on both sides of live coding interviews multiple times. I generally agree with the author, but I don't think any of the issues he brings up are insurmountable. When I'm the applicant, I make it a point to take control of the narrative by saying something like: > If it's alright with you, I'd like to approach this as an opportunity to expose how I approach problems in general rather than how I'd solve this specific problem. I'll speak stream-of-consciousness as I go through it so you can get an idea of how I'm thinking about it. Feel free to ask questions if you'd like; I'll rely on you to decide whether it's more important to you that I complete the task or explain my reasoning. I'm happy to switch to pseudo-code or just discuss potential approaches if we run short on time. When I'm the interviewer, I open with pretty much the same thing. My goal is to put the applicant at ease (to the extent that I can) and make it clear what I'm trying to get out of the session: > First, let me say that it doesn't matter to me if you complete the exercise or not. At this stage of the interview process I'm confident that you're more than capable of solving the problem, so lets use this as an opportunity to get to know each other and see if the way we think about logic is compatible. I'd love it if you could point out things you'd change, but don't worry about trying to 'finish' or end up with production-ready code. It's just a means to an end. |
|
|
i had one who could not deal with that at all. he preferred to show me some of the code that he had worked on. fine, i let him do that instead. i passed on him not because he refused the coding session but because we didn't communicate well enough for me to be confident that i could work with him.
as a candidate i would skip the introduction though and just start talking like i would when pair programming, mainly because i'd be uncomfortable to ask for permission first.