You know, one of the things I found most amazing about interviews and the hiring process was that to a large degree, the things that a person says in an hour session determine whether they will get hired.
Yes, not their references or resume (at a certain stage) or what they're able to prove that they coded, but the things that they are able to come up with to say. Doesn't that strike you as sometimes amazing?
Now, that may be a crazy notion and flawed in many ways, but I came to realize the following. The reason that that is often acceptable is that it frequently is a good proxy for weeding out the unqualified. In this sense:
If someone doesn't even know to say that something is important, or that they solved a problem a certain way (regardless of whether you have proof the actually did it), they probably have never even thought about those things being important.
If someone tells you (just offhandedly) that they solved something by jumping right in to doing x,y,z at the detailed level and coming up with the technical solution (the algorithm), but not the project planning or scoping part of it -- they probably have no idea or experience about what's necessary to plan out a project. They may not be good at estimating or communicating. They may be someone who gets lost in the details. If they have no pitfalls to warn against, probably they haven't even seen how a project has gone wrong before. They are probably not a good candidate for a senior developer role.
Whereas, if someone knows to say that they had to do some top level estimating or quick pass of which solutions would be the best from a cost/resource standpoint, consider the timelines to implement and risk of doing so, how to decide who on the team would be put on the project and in what sequence, etc... Then I know that they at least realize these things are important.
(Yes of course you should probe deeper. And I know that this applies to some kinds of roles and not others, but since the article is about interviewing for non-technical people and is often about hiring for a role requiring a higher-level hiring decision)
Yes, not their references or resume (at a certain stage) or what they're able to prove that they coded, but the things that they are able to come up with to say. Doesn't that strike you as sometimes amazing?
Now, that may be a crazy notion and flawed in many ways, but I came to realize the following. The reason that that is often acceptable is that it frequently is a good proxy for weeding out the unqualified. In this sense:
If someone doesn't even know to say that something is important, or that they solved a problem a certain way (regardless of whether you have proof the actually did it), they probably have never even thought about those things being important.
If someone tells you (just offhandedly) that they solved something by jumping right in to doing x,y,z at the detailed level and coming up with the technical solution (the algorithm), but not the project planning or scoping part of it -- they probably have no idea or experience about what's necessary to plan out a project. They may not be good at estimating or communicating. They may be someone who gets lost in the details. If they have no pitfalls to warn against, probably they haven't even seen how a project has gone wrong before. They are probably not a good candidate for a senior developer role.
Whereas, if someone knows to say that they had to do some top level estimating or quick pass of which solutions would be the best from a cost/resource standpoint, consider the timelines to implement and risk of doing so, how to decide who on the team would be put on the project and in what sequence, etc... Then I know that they at least realize these things are important.
(Yes of course you should probe deeper. And I know that this applies to some kinds of roles and not others, but since the article is about interviewing for non-technical people and is often about hiring for a role requiring a higher-level hiring decision)