[hliyan]

I've recently given up on the idea of hiring genius level engineers for jobs that require building CRUD applications 80% of their time. It's a waste of money, a waste of the talent pool, a disservice to the candidate and a future risk to the company as such individuals will inevitably get bored and start over-engineering things to keep their minds occupied. For most engineers (but not all), being able to correctly write create, update, delete and query operations at the database level and API level, and being able to call APIs from the front-end level, with proper error handling, with a decent approach to debugging, is enough.

[ido]

I’ve been a hiring manager on multiple teams and it’s not that straight forward…Yes, I don’t need John Carmack for my non-Carmack-level technical challenges.

But I’ve seen “ok” programmers perform “adequately” (the project got made to acceptable level) but also seen better programmers work 5x faster (without working 5x the hours, or even more hours at all), be able to mostly self-manage, not need constant qa support to make sure the tickets they set to “done” are actually done and able to solve problems creatively (and not need me to untangle the git repository for them if something goes wrong).

They don’t need brains the size of a mountain but a good/great programmer makes a huge difference (even if enough management can make mediocre programmers work out) even on projects that to me seem technically pedestrian.

[ponector]

Really smart programmer will work x5 faster but report as if he did x1.3 faster than peers, using rest of the time for personal development or other activities.

[ido]

I will probably not keep an engineer that performs at 1.3x of a mediocre programmer for long (unless they’re junior and I see potential, I.e. I’m investing in the future). It’s also not about “smarts” but about being a good fit for the job (which includes stuff like being motivated and interested in the work).

That is - an “ok” developer that performs “adequately” is not actually sufficient and it’s have to be specific circumstances for me to compromise on keeping them (e.g. I can’t find anyone better, but historically this hasn’t been the case).

[khaki54]

It's the concept of "you don't need to be faster than the bear, just faster than whoever you're traveling with".

In this scenario, the 5x engineer (who probably isn't getting paid 5x) will do 30% better than their peers. Unlikely that you would fire the most productive engineer on the team. Moreover with better peers, 5x engineer will be inspired to rise to the challenge.

[ido]

Yep I agree with both :) underperforming coworkers are a negative effect not only due to their own ineffectiveness but also their affect on the rest of the team and their motivation (it’s very demotivating to constantly have to pick someone else’s slack). It’s a tough rut to dig a team out of if it sets (which makes it that much more important to solve early enough).

I just think that it’s not really a benefit for the better engineer to underperform either, I know I’ve always found doing well at work (which was usually more my subjective feeling about myself than anything some else told me) less stressful than doing badly (and not any less work than pretending to be busy but not working).

Being a programmer myself I also know what you can roughly get done (I still program maybe 30-40% of my working hours these days). It could be that someone I hire is magnificently productive (relative to myself/my experience elsewhere in the last 15-20 years) and is managing to hit that while also doing other things, if that’s the case good for them.

Anyway part of what makes someone a good fit is that they want to do well and find the work interesting and fulfilling. We work 4 day weeks so they still have time for other projects in their free time (and I know most/all of them have such projects).

[ponector]

I said x1.5 of their peers. Meaning you will fire first other half of your developers.

Also, you may not keep, but there are million of other managers who will be happy to have someone reliable even at x0.9 performance.

[ido]

Sure but in my original example the “1x” guy was not actually an acceptable performer. I just meant someone great could easily be 5x better, not that 1x is the average (their average peer would be >>1x).

I’ve learned from experience that it’s not worth compromising on a mediocre developer (even if in some situations I’d have to). Better take the short-term hit of trying to find someone good.

Also the 5x ones would mostly not be genius level, just actually motivated and talented. I think a lot of people that can do well are stuck in jobs that aren’t a good fit for them.

[cxr]

> but in my original example the “1x” guy was not actually an acceptable performer

It actually was. You said so yourself:

> perform “adequately” (the project got made to acceptable level)

You need to figure out whether you're talking about someone who is acceptable or not.

[higeorge13]

Curious but how do you identify these 5x engineers from a couple interview rounds?

[cybrox]

In our process, we use almost the simplest possible tasks like making an HTTP request to our API and displaying the data im some form and ask people to solve them 'just as they would as part of a project they are working on'.

They get a timeframe and have to quickly elaborate on their process, what they got done and what they didn't get done.

There are drastic differences between candidates. Some barely manage the task or are satisfied as soon as it works. Some over engineer to no end and reason about all the bells and whistles and others write abstracted code without overdoing it, add some tests and rudimentary docs.

The way people approach this simple task and what their threshold for 'solving' it is has told me more about people than any difficult interview question.

[ido]

This is similar to what I do (details depend on the specific position).

[ido]

Not that easy! A valid technical test needs to be custom made for the position and project (or type of project) you hire for and takes a while to both prepare and “grade”. It also then helps in giving you something very specific to talk about at the interview (I always find something to talk about when reviewing the code they submit for the test).

It still won’t have a 100% success rate, the best you can do is hire people you/someone you trust in the team have worked with before and know is good.

[tiberriver256]

You're describing a genius level engineer. At least in today's world of SPAs and microservices.

[hliyan]

And therein lies part of the problem. Just as you don't need genius level engineers to do applications that are 80% CRUD, you don't need genius level technologies either. Hiring the former can lead to the development of the latter.

Sometimes, the LAMP stack will do.

[nine_k]

Sometimes it takes an above-average engineer to go against the fashion and say that a LAMP monolith should suffice. In particular, it requires an ability to realistically estimate the load and the complexity.