I can relate to this. I have pretty good resume - good schools, advanced degree, impressive sounding projects, a long list of publications. My track-record suggests I am at least a 3x engineer.

So when I get into a coding interview, I'm expected to perform as such... but I usually come off as a 0.3x engineer. Like really bad. Forget syntax bad. Forget algorithms bad. I've bombed so bad in a technical interview, the interviewer questioned if I even knew basic trigonometry. They had spent 10 hours interviewing me prior and felt good, but got me in person and suddenly thought I was an idiot.

In each of my jobs, I've had a considerable ramp-up period. I'm talking 6 months or more of feeling completely lost and unproductive. I get in my head and it makes me perform worse.

If I'm not fired in that first period, I'm lucky. Only after about a year on the job I can perform at the level my resume would suggest.

I regularly look things like that up. I am a builder and a problem solver, not a reference manual.

"I'm your Google, anything you'd need to look up just ask me and I'll give you the answer".

Great way to take the pressure off plus it gives you a good idea on how well they ask questions/are comfortable leaning on others. It's a huge plus if I can get a reasonable candidate to admit that there might be parts of the problem at hand they don't understand.

I've written code tests where I'm expected to read the code, find the issues and fix them on paper. But when they take it too far beyond the spirit of what I believe to be a reasonable test of understanding and fixing code, then I write that I'd just for example compile the program and look at the output.

The companies that are most into questions like these seem to be the classic (failing agile) body shops with ridiculous turnover of their talent, which causes them to have to interview even more, which causes in turn for their tests to become even more abstract and worthless.

6 months to get into things is kinda long though. Unless it's super complex things, it should be less. Are you sure you are not exaggerating?

Most engineers can be productive in a month. The 3x engineers take half that.

Do you see how that putting-words-in-others-mouths looks? It's rude and does not contribute too any kind of productive discussion.

I respect your opinion but I find this strategy very strange. (Or maybe I don't exactly understand what you're saying.)

In my view, it would be a dream scenario if the next 10 programmers I hire were all superior to me. If I was the worst programmer on the team, that would be an ideal outcome. Yes, I've been programming for 30+ years but I'm also self-aware of my limitations. This gives me the ability to recognize better programmers and learn from them. If I'm not hiring interns, I do expect (or at least hope) that they are better than me.

Am I competent enough to write a "do/while" loop and knock out FizzBuzz in 5 minutes?!? Sure, but that doesn't mean there aren't better programmers than me. I would consider it a great business skill if I'm able to consistently attract superior programmers -- either to work with me or for me.

Larry Page attracted programmers better than him (e.g. Jeff Dean). Yes, Larry earned a masters degree in computer science but his java programming (the rudimentary 1996 crawler) wasn't considered very good. His employees rewrote the whole thing in C++ and made it scale for billions of pages. Bill Gates hired superior programmers. Mark Zuckerberg hired superior programmers. Etc. etc.

It doesn't seem like it. The next 3 sentences from the thegayngler:

> I have but one qualification. Can they do the job? Are they strong enough that I can guide them into the position I need them at if it is required.

In my mind, programmers superior to me have abilities that would be beyond my knowledge to "guide" them. They can come up with programming solutions I could never think of. It's very realistic that "the qualification to do the job" essentially means they are a better programmer than me.

Presumably, in your mind, "programming" skill is along one spectrum and one focus, as well? I think that's part of what's being talked about here. There are many, many aspects to software engineering/programming (depending on whether you want to classify them differently), and many roads that could have been taken to get to the point someone is at. I see no reason to think that someone that is better or worse than me in one aspect will also be so in every one of the other aspects of the job.

Let me try to restate that in more general terms and you can tell me if I interpreted it correctly: Since programming skill is multi-dimensional / multi-faceted, and it is unlikely for a programmer to be superior in _all_ dimensions compared to another, it is therefore not possible to conclude if one programmer is superior to another.

Is that a fair rewording?

My response is... sure, programming skill can be looked at as multi-dimensional. But so can other real-world comparisons. We prioritize the dimensions that are more important and collapse all aspects into a composite score.

Multidimensions such as choosing a new job: Company X is a 5-minute commute with 4 weeks vacation but Company Y has the newest technology and has lucrative stock options. Yes, it already goes without saying that there's more than 1 aspect of "desirable working conditions" at each company and no single company can claim a superior score on _all_ aspects. We can still weigh all aspects and eventually pick one (and only one) which is superior.

If I hired a "Jeff Dean" type of programmer, it would be an upgrade to my team and my company. Could I search for an "aspect" that I'm better at than him? Well, looking over his expertise[1], it looks like he doesn't have much frontend GUI programming experience. So yes, I guess I could claim superior skill on writing event handlers in C# language for buttons. That's not important though for my assessment. My point is I don't need for programmers to be superior to me in every aspect for me to determine that they are superior overall. (Same as determining which company is "superior" to work for.)

If I was founding a startup and I was the "ceiling" of programming skill instead of the minimum "baseline", my company would fail. I think I'm pretty decent at programming but I have no Dunning-Kruger delusions that I can "train" anybody that can pass FizzBuzz into a "Jeff Dean". I know of no 6-week bootcamp or even a 6-month corporate training program that can claim that feat. What I can do is recognize the programming skills in others that are (overall) superior to mine and hopefully convince the candidates to come work with me.

[1] https://scholar.google.com/citations?user=NMS69lQAAAAJ&hl=en

Well... no. But I think that's my fault, for the most part. I read the part of your original comment that said 'In my mind, programmers superior to me have abilities that would be beyond my knowledge to "guide" them.' as implying all their abilities as being beyond you, but it doesn't specifically say that.

I wasn't trying to imply that it's foolish to try to ascertain if one programmer is generally better than another (as long as some common domains along which to measure are involved), just to note that it's possible to hire someone that's far beyond you in some areas, and behind you in others, with the intention of specifically helping them build in the areas they are lacking (which have application to the job). The result should be a programmer that is, generally, as good or better than you in most areas, making them a more obviously superior programmer, even if that wasn't entirely obvious at the time of hiring.

In short, you can hire for the things that are important that you can't easily improve while allowing deficiencies in the areas that are less important which you feel you can help them improve in.

As a strategy, it has it's pros and cons. As a pro, it's probably easier to find candidates since your criteria is less stringent. As a con, you might find the candidate you hired has problems coming up to speed in those areas they are deficient in (which may be why they were deficient in the first place, instead of lack of experience).

I didn't really express the point very well originally, and just stopped at the opening, probing question.

Ive seen companies literally turn good engineers into underperforming engineers...stifling them with process, tech debt, politics, etc... Then they get angry some people can perform and others can’t under the circumstances and conditions the management created.

I’ve watched perfectly good engineers get fired or forced out for not being miracle workers only for people to later realize there was nothing wrong with the engineer in the first place.

You don’t know who is going to be the best until you work with them. I would advise people to pick people they will like even under the worst of conditions and train them to the way you want them to be.

I also find it remarkable how quick people are to blame the engineer, rather than considering the whole picture (process, tech debt, politics, etc). It's a complicated equation with a large number of variables.

In my experience the manager cares about fit and attracting you to the team, whereas the peers are all looking for reasons NOT to hire you.

Jokes aside; I agree with the advice of hiring people smarter than you in the domains where you won't be paying attention should the company actually take off.

If you're looking to be a founder/CEO level type, doesn't seem to matter what your skill in Java and OOP are, yes? No need to be a water walker.

That's the "genius" of management; they sell an idea and get someone else to do the work.

Imagine a programming ecosystem with e.g. 5 approximately equally popular frameworks. Suppose that someone with this attitude is familiar with frameworks F1 and F2, but never used F3, F4, F5. Put such person in charge of an interview, where equally skilled candidates (i.e. knowing 2 of the 5 frameworks) apply. They will only classify 10% of them as "senior-level" (those knowing F1+F2), and additional 60% as "somewhere between junior and senior level" (those knowing one of F1,F2; and one of F3,F4,F5). So they would hire literally themselves, but probably not someone on the same level.

IIRC a Google recruiter once sent a set of packets to a hiring committee and all of them got a "no hire". Then the recruiter revealed the packets were lightly-anonymized versions of the actual packets of the hiring committee members, from when they'd all originally interviewed.

I wonder how much of that comes from being exposed to all of the consequences any poor decisions they made shortly after they were first hired.

This is so correct.

Productivity follows when people are working for a worthy cause. In fact the core of productivity isn't lists, management techniques or whatever, it is a thing called 'constancy of purpose'

There exist no such a thing called 10x burger flipper.

If you don't encourage a culture where everyone is asked to hire people better than themselves, it can easily degrade where each progressive hire is slightly worse.