Live data from Hacker News

Not a real engineer (2019)

twitchard.github.io

51–60 of 86 posts

Re: Not a real engineer (2019)

#51
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.

Re: Not a real engineer (2019)

#52

I was recently unemployed and this hits home. The morons who rejected me had no fathom of an inkling of a tenth of what I’m capable of.

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?

Re: Not a real engineer (2019)

#53
post #44

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 i…

> 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…

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

FizzBuzz is not a high bar to pass.

Re: Not a real engineer (2019)

#54

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…

What are some examples on how a non coding skillset makes you a better engineer?

- ability to communicate effectively with multiple stakeholders

- ability to plan and estimate

Re: Not a real engineer (2019)

#55
post #51

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 wr…

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

Re: Not a real engineer (2019)

#56
post #51

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 wr…

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

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.

Re: Not a real engineer (2019)

#57
post #51

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 wr…

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.

Re: Not a real engineer (2019)

#58
post #57
post #51

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 wr…

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…

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

Re: Not a real engineer (2019)

#59
post #57

Earlier quoted context omitted.

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…

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

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.

Re: Not a real engineer (2019)

#60
post #57

Earlier quoted context omitted.

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…

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

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.

Post reply on HN