|
|
|
|
|
by personZ
4368 days ago
|
|
Explaining your thought process to a coworker after you've written the code is ex post facto rationalization -- you are invariably leaving out many side-tracks, many missteps, and get to condense down a long process into a simple, seemingly obvious explanation. You already see the route, and now you're just describing it. Trying to do the same while you're trying to solve the problem, with a judgmental crowd scoring your comments, however, is an absolutely and completely different matter. Even thinking about how I would narrate my thought process as writing this reply ("maybe I'll talk about how I'd narrate the writing of this reply") is confusing enough. I don't disagree with the concept of technical interviews, especially given that there are countless people who hold none of the skills they claim they have mastered. A process I implemented requires developers to come in for a coding test, where they are equipped with a development machine with full internet connectivity and a full toolset, and given a problem within their skillset to solve, alone in a closed office and for as much times they need. After the test we do talk through their "thought process" and their implementation choices. I know this offends some people, among whom I'm sure are the people who completely failed to demonstrate even a basic knowledge of skills they claimed an expert level of competency at. |
|