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.
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.
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.
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).
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.
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).
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.
Did you notice the quote marks around adequately? We managed to hobble along but it was obviously not going great. "It wasn't catastrophic" isn't my goal. I want stuff to go really well, not just about enough to not go out of business/not be in violation of contractual obligations (with a lot of slack getting picked up by their better performing peers).
Again it depends if you have an alternative, in my experience I always had it was just sometimes costly/inopportune/a pain in the ass in the short term to find someone better. Long term it was always better (I never regretted firing someone too quickly but often regretted firing someone too late).
I was also always worried about team morale but every time a low performer was fired it actually improved morale.
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.
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.
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 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.
I just recently got into Steve Howe. He's considered one of, if not the best guitarist of all time and I came across a quote he had that said something like he wished guitarists would focus on being musicians. Same thing as coders to engineers.
I've come across more technically able programmers than I am. But they aren't better engineers. And a lot of that is because I'm an entrepreneur and have a marketing secondary background as well.
So many companies discount non coding skillsets that actually make one an engineer in my opinion.
They hire the butcher instead of the chef and then wonder why it tastes like shit when it's cooked.
You're onto something but it flies in the face of a bit of convention as you're probably not the standard personality that gets into engineering.
I think it's a fine career to go to school, get your BS in whatever technical field you choose, and work as engineer #52354 at Ingersoll Rand, or Boeing, or whomever, and retire after 30 years of being master of your highly complex but perhaps limited domain. That is a very valid definition of an "engineer". These people probably have very fulfilling personal lives that you'd probably see as miserably boring, and that's okay.
I've thought hard lately about this sort of thing, and one thing that seems clear to me is that management likely sees the "standard engineer" is a cost sink where someone like yourself may escape that sort of criticism as your value transcends just engineering and into other departments that directly generate revenue.
For what it's worth, we sound like the same type of engineer but I've worked to try and turn what may be contempt for the stereotype into something more... collaborative.
I learned how to time things and operate a system in parallel by working in commercial kitchens. I learned how to work with people and not be disheartened by them through working retail. And wrenching on cars requires diagnostics and logical thinking to determine what is actually broken without throwing a pile of parts at the problem.
There are many ways to play a guitar.
The Iron Maiden guitarists, blew away everyone else in the early 1980s with their guitar solos(and playing in harmony). They had mastered pretty much every technique you can use on the electric guitar. Tapping, etc.
Yet, they can not play like Paco De Lucia, who finger picks a nylon stringed guitar. And Paco De Lucia can't play like they can. So who is really best?
There is no best musician. Not just because there are a multitude of different skills that go into it, but also because nobody agrees on what weight to give to each of them or even what they are. This makes it impossible to make an absolute ranking. At best you would get a Pareto front made up of the greatest.
Any time somebody makes a claim that their passionate judgment about a subjective topic is objectively true, that’s a bit-flip moment for me. Doesn’t mean I will ignore them, but we are now having a different conversation. They are a “fan” and discussions with fans are often not that interesting.
And fwiw, Paco De Lucia is technically skilled to a fault, but does very little for me.
"There was mention of Paco de Lucía, who is the greatest, well, if not the greatest ever flamenco guitarist. Many people love him dearly as I do, and if somebody says, 'Can you play like Paco?' I say, 'No, no.' [laughs] So I just jumped on board, and it was wonderful. Very nice people." [1]
Howe made up a flamenco piece on the spot for a Queen song so he was talking about Paco then.
The nod is there by the man himself for the greatest flamenco guitarist.
But if you discuss something that is basically subjective, you still need criteria because if one person is saying oh Paco is the most technically skilled that's one thing. Another would be more akin to how the Decathalon decides the greatest athlete.
I don't know if Howe is the best ever, but if there was a Decathalon equivalent for guitarists, I'd bet Howe would top Paco no problem. And in that event, he'd top Jimi Hendrix and Page too. But that's just my benchmark, having range and full command of the discipline.
I’ve lived both sides of this. I’ve been subjected to the mysterious whims and casual insults of the job-seeking process. I’ve also interviewed and rejected experienced candidates who talked a great game but couldn’t demonstrate the ability to code FizzBuzz-level problems in any language.
It’s not a choice between “the tech interview sucks” and “the job market has many unqualified candidates.” Both can be true, and in fact I think they are related in a market-for-lemons way.
> I've lived both sides of this. I’ve been subjected to the mysterious whims and casual insults of the job-seeking process.
I've grown to learn that it's important to understand that interviewing in particular and job-seeking in general is not an objective and impartial process, and the output is not deterministic or reproducible. You can be hired even when there are objectively better people in the race, and you can be sidelined right on the phone screening even though you are the ideal candidate. It's a crapshoot, and the only people claiming otherwise are motivated by a mix of survivorship bias with a need to avoid recognizing that the process is flawed by nature.
> I’ve also interviewed and rejected experienced candidates who talked a great game but couldn’t demonstrate the ability to code FizzBuzz-level problems in any language.
I'm afraid that this take is also a reflection of the cargo cult mentality that plagues recruiting. I personally know FANG engineers with half a dozen years of high-profile work who had to spend weeks training coding golf and algo&data structures trivia before passing the first round of interviews, all because these trivia games bear no resemblance with real world software engineering. In fact, I will go as far as to claim that they serve more as ladder-pulling than actual technical assessments. For example, once I was automatically rejected from a C++ position to work on a desktop app because I wasn't familiar with placement new. This also extends to framework tests. I know a guy who applied for a backend position who was rejected because even though he rolled out a Spring service from scratch that passed all integration tests, the interviewer complained about how the service did not commented the controllers. These are things that takes a single comment in a PR to address. I mean, is adding a comment w challenging technical feat? But somehow some interviewers reject candidates based on this nitpicking.
> I personally know FANG engineers with half a dozen years of high-profile work who had to spend weeks training coding golf and algo&data structures trivia before passing the first round of interviews, all because these trivia games bear no resemblance with real world software engineering. In fact, I will go as far as to claim that they serve more as ladder-pulling than actual technical assessments...
FizzBuzz is a trivial technical problem, though, not a leetcode medium or even an easy. I agree with you that you shouldn't have to grind leetcode all day in order to be considered a valuable software developer; but the existence of people selling themselves as "engineers" but who can't solve fizzbuzz would go a long way towards explaining how we got into this leetcode situation in the first place, because such a person would not be able to be successful as a software developer and they need to be weeded out during the candidate search somehow because they are around and they do want the job.
No, it is not. The term fizzbuzz doesn't refer explicitly to the loop with the modulus example. Fizzbuzz is an umbrella term for tests that are used to assess proficiency, but in practice they tend to have weird gotchas that get you disqualified for random reasons.
Case in point, there are online coding challenge tests where you do fizzbuzz tests that flag you as disqualified for cheating if you move your focus away from the page. That's one way to fail fizzbuzz tests: you start the test, switch your browser window, boom you're tagged as an incompetent moron.
I said “FizzBuzz-level.” I’ve used actual FizzBuzz for new grads who I suspected couldn’t code, but normally I’m using questions that require looping, conditional logic, perhaps the use of a simple helper data structure like a map. I consider “reverse a string” to be advanced FizzBuzz. Anything requiring DFS or binary search is not FizzBuzz. “Print a tic tac toe board using asterisks, one character at a time” is FizzBuzz.
> I personally know FANG engineers with half a dozen years of high-profile work who had to spend weeks training coding golf and algo&data structures trivia before passing the first round of interviews
> all because these trivia games bear no resemblance with real world software engineering
You may actually agree with GP for he is not talking about that. GP is talking about FizzBuzz: less than ten lines of code and three if or something.
Someone who cannot solve that cannot code, as simple as that. I don't care about a little error but someone who doesn't know how if and else do work has no place in "real world software engineering".
I mean: how many developers working on critical systems like those in a commercial airplane don't know how a conditional statement work?
Anyone who has ever interviewed candidates knows there are master bullshitters out there.
As one CTO once told me before I'd be interviewing people: "When you look at their CVs full of buzzwords, you'll often feel like you know nothing. But for many of them, once you'll start asking trivial questions you'll quickly realize they're the ones who know absolutely nothing".
Asking to solve FizzBuzz is not asking to solve a problem which requires to know when to apply, say, Floyd-Warshall.
I’m at a FAANG-type company and have interviewed over 1k engineers at all levels, but mostly senior+. The coding questions I ask aren’t literally FizzBuzz, but do involve counting, looping, conditionals, etc. Good solutions are possible in 30m and take 30 lines of code or less. And I’m not looking for beauty or perfect efficiency, I’m looking for code that works and which the candidate can explain.
Example: given the x/y coordinates of a rectangle, can you write a function that tells me which points in array are inside or outside?
Other companies may get a different pool of candidates, so such a low-pass filter may not be necessary. But these people have resumes which describe them as capable engineers. What I usually find is they are no longer coding much, but are doing design reviews, code reviews, and attending meetings.
>I know a guy who applied for a backend position who was rejected because even though he rolled out a Spring service from scratch that passed all integration tests, the interviewer complained about how the service did not commented the controllers
yeah, and though the job advert says "spend 1 hour on this", you find that 1 hour isn't enough. And yet, the interviewer will pick up faults "you didnt finish this"
Candidate seemed like a good fit until I saw something inexplicable, a black tongue, dark as sin, slithering out of the candidate's mouth like a serpent, writhing about as if it had its own mind, and when it touched Tim (the shadow interviewer) he collapsed on the spot as if struck by a lightning. I don't remember how I got back to my seat. 1/10, DO NOT HIRE.
P.S. Please send someone to check up on Tim because he's now back wearing a strangely looking robe with a scythe taller than himself. Yes, the scythe seems real. No, I didn't test.
The problem with Vishnu is he is limited to only having four arms and two ears, which of course limits Vishnu to supporting at most two production systems and, therefore, not being able to handle "web scale."[0]
The people doing hiring make mistakes - it's a bloody difficult thing to do successfully. They also sometimes save you from working in a place with people you wouldn't like much anyhow. They're not really good at coming up with excuses why they didn't select you - it's a crap shoot. Perhaps they get a "not a Trump supporter" impression from you and that makes them feel like you'll never fit comfortably. If you really aren't their kind of person why would one want to work there?
The search for a job always puts me in a depression and I haven't got any answer except that you have to not hope too much about any one job - or be too dismissive of one that doesn't seem quite so amazing. You just cannot tell what will happen - my first boss in my current job turned out to be horrendous and there were not nice people working there and ...... they left the company! I got promoted. How could I predict that? The hiring people cannot predict you either - it's all a bit of a random and uncomfortable process.
When I'm on the other side of the table I've got some priorities:
1. My boss gave me a short bit of advice which is "try to hire nice people." I'd rather work with good developers who can be friendly and help each other and get along without always having to get their way than people who think they are highly productive geniuses and deserve to be in total control.
2. Is the candidate interested in software, or indeed anything. If they are not a bit enthusiastic about software, technology or something relating to the work then how will they learn the things they need to know that aren't on their CV? One should expect people to need to learn and not come "ready made."
I think that people in the software industry usually have quite a lot of options. Sometimes you might have to be prepared to move or to take a salary hit, but of all professions it seems to be quite a good one to be in at the moment - at least where I am and compared to everyone else.
I would argue that a good interview process will certainly reject some candidates that would in fact end up performing very well at their job. To really understand if someone is good for the job, it would be very costly in terms of time spent in the interview process, both for the employer and for the prospective employee. It’s a poor allocation of resources by the employer and the candidate wouldn’t stand for it either. To judge a candidate, I wish they could come to our office and they have a full day to work solo on completing a small coding project. It’s just not practical.
I love it! Reminds me a bit of the protagonist of Aphyr's Verb-ing the Technical Interview series, with the parentheses of salt and bough of cloud pine and deep arcane knowledge.
At my last interview, the much younger fellow interviewing me asked me to tell him about myself. I was doing to devote a single sentence to what I did before going to university, as a backdrop for what my motivations have been; this kid cut me off in the first sentence of my interview and told me he wasn't interested in any of that.
It really taught me how much power we can have when we control timing. I was off for the rest of the interview. Even at a good interview, how can someone get to really know you in such a short period of time?
My favourite, slathered with a generous amount of sarcasm gravy, is:
They feel they have candidates who are a bit stronger
coding wise that fit their needs right now that they
want to proceed with.
This said twice.
Once before any interaction at all and the same after an initial meeting when the technical interviewer had not bothered to review any of multiple FOSS projects made available beforehand.
lol... I'd rather not... but that is only because some know where the word came from.
The phrase "Hoist with his own petard" comes from the young "Engineers"/soldiers tasked with breaching a castle door by rigging a bell shape charge, and sometimes getting tangled in the rigging.
Some mistake it as a wonderful title like Dr. or Mayor... others it is a job function like plumbing.
Yet very little has changed people wise in modern technology, and regulatory capture is rather popular. Strangely, these same places often also still charge money for bathroom access.
Engineer, Journeyman, Entrepreneur, and Tinkerer are all often still class specific pejoratives in some circles.
So it's not just me then. Is it implying that software engineer job adverts are fake?
If the problem is oversupply of talent, you'd think salaries should drop as people compete for limited jobs... But that would only be the case if we had a free market.
I feel like to get a job as a software engineer, you have to pretend to be brainwashed. Just act very friendly and optimistic, pretend to be member of a minority group and make sure you tell them that you're fully vaccinated and boosted. Also, use a stage name on your resume instead of your real name and a separate email address.
The way I interpret the poem's message is that sometimes hiring can concentrate on the wrong estimators of ability, ignoring indicators that the applicant can open a can of whoop-ass.
Interesting - I interpreted it as how it feels to take rejection very personally - someone not getting the job feeling like there is something deeply wrong with themselves
I also interpreted it this way. Despite your knowledge of who you are and what you believe you have to offer, job interview rejection can feel like a personal attack.
Of course you’re not a fit for this role, why would you ever apply? We considered you before we knew who you were. But now we see you as you truly are. Monstrously unqualified. Your 15 years of experience in distributed systems is nice, but we’re really looking for someone who could invert a binary tree in 10 minutes, and, well, you were on track for 20+ before we kindly stepped in and asked if you had any questions for us.
I thought this as well. At my shop, everyone in the hiring chain has adopted the "Talent Acq" mindset. Even engineering managers just do Keyword matching for skills. No one thinks about the problem needing to be solved and that maybe, just maybe, complex problems require people who can "open a can of whoop-ass" on them. That's a gift, not a skill and it does NOT fit the process.
Businesses desire either money printing machines or money printing operators. Generic printer architects are rarely needed because they’re not specialized in printing money fast. Nevertheless postings say they’re looking for architects.
You need to (pretent to) be a conformist which is important to work in a team, especially in larger companies. Ability to accept compromise, work in conditions far from ideal, set aside unimportant differences. Being e. g. anti-vaxxer isn't often problem per-se, but it's a sign the person might be difficult to work with in a team setting.
It's similar with e. g. positive discrimination, I think many people silently object, but not being able to filter it out in business context is a bad sign.
“we’re looking for somebody more technical” = Yes, they are looking for that savior to solve all problems—-problems that hiring manager/hiring group/hiring company want to solve. Yes, where is that person? where is he/she?
"The job posting clearly asks for seven stars and seven candlesticks, yet the candidate only demonstrated five stars and no candlesticks during the interview. Hard Pass."
