No. The difference between talking (very intelligently) and doing is huge, and a sports analogy might be illustrative. If you ask detailed questions about football to hire a NFL quarterback, your most intelligent responses will probably be from a coach. “How should you change the position of your right shoulder if you see that a fast edge rusher is approaching you from the left side and you have two open receivers?” A coach like Bill Belichick might have a fantastic, detailed answer demonstrating a thorough understanding of every aspect of football past and present, but he could never make the throw himself.
That analogy highlights what’s irritating me about this post and this entire thread discussion - there are 1,696 players in the NFL, each with an average salary of $1.9 million. When people talk about hiring “senior engineers”, they behave as thought they’re auditioning an NFL quarterback - the 1 out of 100,000,000 people who can actually perform at that level. For a salary of, on average, about $100,000. When you start out - offering comparatively little but looking for Tom Brady, you’ll pass over pretty much everybody, because the person you’re looking for won’t just not interview with you, they probably don’t exist. After a few months, you’ll relax your standards, and after a few more, you’ll relax them even more and end up hiring a comparative retard like myself - somebody with only a mere 25 years of hands-on development experience and a bachelor’s and master’s degree in CS along with a couple of publications. But if I presented in the first few rounds of interviews, back when you were looking for the guy who could derive the tortoise and the hare algorithm in 30 seconds in front of five people in a boardroom, you would have passed.
> The difference between talking (very intelligently) and doing is huge
To be fair it is environment dependent more than anything else. Forget competence, charisma, intelligence, and everything else about the candidate that could bias their selection and instead look at processes and code already in place the new candidate is jumping into. Does the environment strongly favor original ideas/solutions or does it dictate the narrow acceptance in the most narrow of boundaries?
I have been on both ends of this as well. It is common in software for shops to define success in extraordinarily shallow terms such as whether you are using spaces versus tabs and indenting properly. Another example I experienced last year is whether you should write a giant monster configuration or a small function that receives a single argument. The reasons why shops coat themselves in blankets of code style and configuration is because they typically don't trust their developers and instead strive for a normalized baseline. They are looking for wonderful solutions, but rather task completion.
The lack of conformance isn't necessarily an indication of lower capability, but it is an indication of incompatibility. Competence and conformance are wildly out of sync when the candidate is misjudged relative to the work available. That is completely an assignment failure opposed to a candidate failure. Having gone through this myself it has taught me to ask very probing questions, as a candidate, during the interview. If, as a senior, I can determine I will not be a good fit I will happily disqualify myself.
> A coach like Bill Belichick might have a fantastic, detailed answer demonstrating a thorough understanding of every aspect of football past and present, but he could never make the throw himself.
Would you really hire a coach to be your quarterback? Is that a thought you would really entertain? Even if that coach could do that job he/she would be more valuable doing other work. I would consider this a solid example of interviewer/assignment failure.
> Having gone through this myself it has taught me to ask very probing questions, as a candidate, during the interview.
Like what questions? I'm assuming the work you're looking for is more along the lines of "wonderful solutions" as opposed to "task completion" - is it as simple as asking, "How anal are you guys about code syntax and whatnot?" and, "How hard are your problems actually?"
Here are some I thought of off the top of my head. These are based upon things I actually encountered.
What if I were to provide a solution that executes much faster, requires less documentation, passes test automation, and is a quarter of the code but ignores the framework or standard code style?
The standard DOM methods perform thousands of times faster than other options for interacting with markup. I can prove this with numbers. Code like that is not popular. Will I be allowed to write unpopular objectively superior code?
If I can reduce the application build from 5 minutes to 5 seconds will you let me rewrite the build from Java to Typescript?
A/B testing is a powerful way to determine preferential user behavior and a measured increase in conversion. Will I be allowed to write inward facing experiments to test developer behavior?
What if I provide a function as a solution the makes use of scope and nested functions but offers no support for inheritance?
Is it better to complete a task in 1 hour with original code plus tests or extend existing components with risk of regression and 4 days of effort?
A couple of these questions would be at least yellow flags for me as an interviewer or hiring manager, as they indicate a strong bias for throwing away existing systems ("ignores the framework", "rewrite the build", "original code").
There's a great quote from Lou Montulli[1]:
> I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.
Those frameworks and existing components most likely have a lot of hard-won experience embedded in them, and I would be uncomfortable hiring someone who did not appear to understand or appreciate that.
That is why I would ask those questions... to excuse myself out of your organization. I have found it painful to be at organizations who repeatedly and intentionally make really bad decisions so that their developers deliberately don't have to solve problems (invented here syndrome). If that is what I were looking for I wouldn't have developed the skills that I have.
Maybe this is unique to sports? Do other fields exist where a BB-esque expert is totally incapable of practicing? The greatest movie critics probably can't direct or write for crap, but they're not commenting on how the movie was produced, just its output
From what I have seen, most of the academic research principals in computer science are not actually practitioners anymore. They are more like coaches. The actual code is written by graduate students, and most of it isn't even very good because the code isn't the point in most cases.
Not unique. One could convincingly argue that this effect exists in many fields. Art (ie art history major vs artist). Music (ie violin player vs film score composer). Restaurant reviewing (ie critic vs chef). I'm sure there are many more.
Why talk to someone so condescendingly? I mean, what percentage of people do you epxpect to HAVE seen this bit of obscure media you seem to hold as seminal?
> The greatest movie critics probably can't direct or write for crap
They may know a lot about how a film is made. It does not follow that they could sit in the director's chair, or write a decent screenplay. (And yet, they could still be great at critiquing films!)
This is a valid point. Just knowing how something is made doesn't necessarily mean you know how to make it. It's the difference between a designer and an implementer. Or architect and builder.
