Hacker News new | comments | show | ask | jobs | submit login

Most engineers would not hire themselves. That has been apparent to me for awhile now. I’m not sure why they expect people to be to be better than they were when they were hired. I don’t expect engineers to be better than me. 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.

So much focus has been put on 10x this and high performing that. Companies waste lots of engineering talent and company money looking for 10x when 10x is mostly situational in nature. Set the scene. In one scene the engineers are not producing. Change the scene and now they are 10x.

Instead of looking for 10x, that time would be better spent making incoming and current engineers better at their jobs and creating 10x situations.




> Companies waste lots of engineering talent and company money looking for 10x when 10x is mostly situational in nature. ... In one scene the engineers are not producing. Change the scene and now they are 10x

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.


Forget syntax bad. Forget algorithms bad.

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


I love to flip that around in an interview before it even comes up, one of the 3 things I start out any interview with is:

"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.


This is fantastic. Often I am wondering should we start test how good engineers are in asking questions for search engines. I am not going to write the perfect compilable code for them, I have a tools to tell me if I forgot the semicolon in line 31. I don't need to remember standard library 100% and recall all functions' signatures - I have a docs for that. But I should be able to ask meaningful questions that get me closer to the answer and I should do it efficiently. We have tools now, we should start using it instead of memorizing things.


I love this! Thanks for sharing!


"I'm not a reference manual." I'm going try to remember that to use in an interview some time when I don't know something off the top of my head, and they get in my face for it.


You probably wouldn’t want to work anywhere where people get in your face for not knowing something off the top of your head. The three phrases I wish that I heard more frequently at work are “I don’t know”, “I’m not sure” and “Do you have any ideas?”


Well said.

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.


I have a long text file that I copy and paste out of that has pretty much everything I ever do from read/write from databases to displaying data 90% of everything I do is a variation of the same thing.


Forgetting syntax shouldn't be a problem. That's what manuals are for. Of course, if you are applying for a Java programmer job and you don't know the first thing about how Java program looks like, it's a no-no. But if you forgot some detail about how to write some obscure construct - that's what manuals and SO are for.

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?


Even after hiring, it's not uncommon to be asked "Do you really know . . .", especially after forgetting a detail in discussions.


6 months? That's terrible.

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


There's a difference between "feeling unproductive" and actually being unproductive. The person you're responding to said the former, not the latter. And in my experience it's nearly universal that when you ask excellent and very senior engineers "how long did it take you to feel ramped up?" they answer "I still don't!" despite having been there for months/years.


Had few jobs in low level system codebases in the millions of locs. I've had 9 months probation periods.


Nine months is insulting unless you guarantee me a VERY generous severance if things don't work out.


So you weren't productive during that entire time?


There’s a reason people refer to it as “ramping up”, as you become familiar with the environment and code base you become more and more productive until more or less plateauing a while later. It’s not really useful to categorise it as binary productive or not productive.


So you are telling me you never qualified at a workplace with longer than a month probation period?

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


[flagged]


I'm wondering if you find it ironic that you feel attacked in a thread you started with an attack on me?


Depends entirely on the system you are working with.


>I don’t expect engineers to be better than me.

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.


You actually agree with each other. You're saying "it would be a dream scenario if the next 10 programmers I hire were all superior to me"; it's an ideal outcome, even if unlikely. The parent's "I don’t expect engineers to be better than me" merely points out the unlikeliness, you point out the desirability.


When I was at one company (later acquired by Google), one of the developers created a model to show just how unlikely it was that every new hire would continue to raise the average level of competence for the team as a whole (as our hiring traditions espoused). After years of hiring very good programmers, it just wasn't going to be possible to hire many more who could pass that test.


Could you elaborate on the hiring process? Was it calibrated to hire people more competent than X% of the current engineers?


>You actually agree with each other.

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.


> In my mind, programmers superior to me have abilities that would be beyond my knowledge to "guide" them.

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.


>There are many, many aspects to software engineering/programming [...] 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


> Is that a fair rewording?

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.


Of course you want the best you can get. I’m arguing 10x is constantly influx for any number of reasons. So it’s unlikely you’ll get one. If you have a process for making engineers into the best then you don’t need to look for the unlikely 10x because you can make them into the 10x high performers you need.

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 have observed exactly the same thing. It's truly mindblowing.

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.


I recall one of my friends, when I was at Google, sending me a screenshot of code written by Jeff Dean with an obvious bug. Jeff is, of course, extraordinary, but I wonder how many companies might have passed on him if he submitted that code in an interview setting.


Absolutely. There exists no single human being that does not make any mistakes. The trick is to find the people that make as few as possible, know how to track them down, and that can figure out how to hot-fix them as needed.


This anecdote made my day. Thank you for helping assuage my Imposter Syndrome.


I believe he is referring to the case of the interviewer being a peer rather than a manager.

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.


Java in 1996 was version 1! Doesn't necessarily say much about Larry'd code-foo :)

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.


I noticed that quite a few programmers have the following attitude: If there is something (a programming language, framework, library, paradigm, design pattern, tool...) that they know and use, then they believe that familiarity with it is essential to call yourself "senior". On the other hand, if they do not use it, because they do not know it, they believe that it is useless and anyone studying it is just wasting their time. They may not be aware that this is the algorithm they are using to evaluate others.

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.


Most engineers would not hire themselves.

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.


Agreed. I wouldn't even mind so much if they picked "better for the job". So often, it seems like the criterion is "better at doing things that never actually come up in the job".


It has to do with companies looking for people to be off the shelf cogs/resources instead of having a plan for training & growth.


Agreed. They say here’s your $250 training budget and leave you to it...thinking they really did something.


>>creating 10x situations.

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.


> Most engineers would not hire themselves... I’m not sure why they expect people to be to be better than they were when they were hired.

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.


"A players hire A players and B players hire C players" - Steve Jobs (Maybe?)

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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: