Live data from Hacker News

Show HN: A Senior Engineer's CheckList

news.ycombinator.com

71–80 of 155 posts

Re: Show HN: A Senior Engineer's CheckList

#71

'Get involved with hiring for your team and company, and maintain a high bar for hiring quality candidates.' Posts derailing this 'high bar' are posted semi-daily to Hacker News, no? It's a really big dilemma (extensive hiring process that weeds out good candidates due to time and frustration or take risks) and it makes it sound like it's just something, you can, you know, do on a Tuesday in your spare time, and then…

The "high" in high bar is not a particular useful measurement. What is high? Unless you've defined what that means, and everyone involved understands and agrees what that means, it's just a word. What you can say is "we need someone who knows the internals of tool X, and we measure it via Y". Basically, avoid using adjectives to measure things (e.g. say 1 liter glass, don't say big glass).

The only "problem" with that approach is that it invalidates most hand-wavy advice:

"Make everything as simple as possible but no simpler." All well and good if your requirements are written in formal logic or if there is only a single axis along which complexity can be measured.

"Hire only the best." What if the best only want to work with the best pay and the most interesting work? But "hire only the best of the very few who are willing to work on your projects for the kind of pay you're willing to offer, who will consider it a blessing that they were hired at 20% above your minimum starting salary with no other career avenues than management, and who are naive enough to think of options as valuable rather than lottery tickets" isn't quite as snappy or happy.

"Don't be evil." And since you have that slogan anything you do is by circular logic not evil. Handy.

Re: Show HN: A Senior Engineer's CheckList

#72
post #70

'Get involved with hiring for your team and company, and maintain a high bar for hiring quality candidates.' Posts derailing this 'high bar' are posted semi-daily to Hacker News, no? It's a really big dilemma (extensive hiring process that weeds out good candidates due to time and frustration or take risks) and it makes it sound like it's just something, you can, you know, do on a Tuesday in your spare time, and then…

I wonder where people work where they can become a senior engineer in the first place without getting involved in hiring.

I'm a senior developer and have almsot zero involvement in hiring.

PRevious place I worked had probably a hundred senior developers and none of them had any involvement in hiring.

IME the only developers that get involved in hiring is architect level and Lead Developers.

Re: Show HN: A Senior Engineer's CheckList

#73

'Get involved with hiring for your team and company, and maintain a high bar for hiring quality candidates.' Posts derailing this 'high bar' are posted semi-daily to Hacker News, no? It's a really big dilemma (extensive hiring process that weeds out good candidates due to time and frustration or take risks) and it makes it sound like it's just something, you can, you know, do on a Tuesday in your spare time, and then…

Especially nowadays when Developers don't seem to have to be required to actually be able to code.

I'm not part of the hiring process at our place but from what I've tried to contribute as a potential technical test, I get told it's too hard... It's really really not hard at all. But from what I can tell if you ask them to code, even in their own time or in the interview, that's unfair and stressful and you aren't seeing them at their best. So you ask questions instead of asking them to code, but then developers don't remember stuff they can just google nowadays. Again, you are being unfair and it's too hard for them!

We really seem to have allowed the infantalization of our industry, it's very depressing. Maybe the answer is just reject anyone under 35?

Re: Show HN: A Senior Engineer's CheckList

#74
post #70

'Get involved with hiring for your team and company, and maintain a high bar for hiring quality candidates.' Posts derailing this 'high bar' are posted semi-daily to Hacker News, no? It's a really big dilemma (extensive hiring process that weeds out good candidates due to time and frustration or take risks) and it makes it sound like it's just something, you can, you know, do on a Tuesday in your spare time, and then…

I wonder where people work where they can become a senior engineer in the first place without getting involved in hiring.

I've been a "senior" engineer for years, in that time I've read through a few dozen CVs, sat in on 2 interviews, and had final say in hiring of exactly zero people. I suspect the same is true for at least half the senior people here, unless they also happen to managers.

Re: Show HN: A Senior Engineer's CheckList

#75
post #71

Earlier quoted context omitted.

The "high" in high bar is not a particular useful measurement. What is high? Unless you've defined what that means, and everyone involved understands and agrees what that means, it's just a word. What you can say is "we need someone who knows the internals of tool X, and we measure it via Y". Basically, avoid using adjectives to measure things (e.g. say 1 liter glass, don't say big glass).

The only "problem" with that approach is that it invalidates most hand-wavy advice: "Make everything as simple as possible but no simpler." All well and good if your requirements are written in formal logic or if there is only a single axis along which complexity can be measured. "Hire only the best." What if the best only want to work with the best pay and the most interesting work? But "hire only the best of the ve…

"Hire only the best." What if the best only want to work with the best pay and the most interesting work?

That's the interesting question. The hard choice, that I rarely see discussed, is what to do when "the best" won't work for you. Do you hire the "perfectly adequate" or do you not hire and not do that thing you want "the best" person to work on.

Re: Show HN: A Senior Engineer's CheckList

#76
post #70

'Get involved with hiring for your team and company, and maintain a high bar for hiring quality candidates.' Posts derailing this 'high bar' are posted semi-daily to Hacker News, no? It's a really big dilemma (extensive hiring process that weeds out good candidates due to time and frustration or take risks) and it makes it sound like it's just something, you can, you know, do on a Tuesday in your spare time, and then…

I wonder where people work where they can become a senior engineer in the first place without getting involved in hiring.

This is probably far more common than we'd like to admit.

I've certainly worked in places where they'd rather I didn't get involved in the hiring process. These kind of places often heavily relied on external recruitment, and would rather that I spend my time working on projects than potentially rejecting candidates that could do the job, but weren't up to my standard.

These aren't non-tech companies either - these are companies that deal in/sell tech as a project and/or service. Even in companies that live and die by their development team, non-technical management can run the show and dictate hiring.

Re: Show HN: A Senior Engineer's CheckList

#77
post #74
post #70

Earlier quoted context omitted.

I wonder where people work where they can become a senior engineer in the first place without getting involved in hiring.

I've been a "senior" engineer for years, in that time I've read through a few dozen CVs, sat in on 2 interviews, and had final say in hiring of exactly zero people. I suspect the same is true for at least half the senior people here, unless they also happen to managers.

I'm not trying to sound accusatory, I'm just interested. Aren't you interested in choosing the people the people you're going to have to work with every day? Are managers doing interviews where they're asking technical questions?

Re: Show HN: A Senior Engineer's CheckList

#78
post #53

About this one: > Respect code and systems that came before you. There are reasons for every code and every guard that exists in production Sometimes there's bad code in prod, or code that doesn't need to exist anymore. You should try to understand when something is there for a good reason versus a bad reason. Cut out the bad code, keep the good code. I've seen a lot of cases where people assume that current code is…

I think the main thrust is respect the code and understand why it was there. Don't start with the possible initial feeling that a particular piece of code or guard is not needed. If you do find that it's not needed, remove it or fix it.

I'll second manojlds's comment. If there is bad code/design decision on production - it not necessary means it was bad all the time. Software grows, requirements changes and it is very likely there is a reason why the code is as it is now. Even if it does not solve the problem efficiently today.

People also tend to forget human and business impact. The code might look different if there is 1 week or 4 weeks given for implementation. Timelines, pressure from management/stakeholders to deliver faster has impact to made solutions and implementations.

That is when respect is needed - having empathy to understand why this part of software looks like it is now.

Re: Show HN: A Senior Engineer's CheckList

#79

These are excellent, except for one, which is to avoid politics. Politics is the art of making other people want the things that you want. If you can't do that, you're not a senior engineer. Politics is critical for your success, and honestly, a large number of these sixty points fall under, IMO, politics. tl;dr: s/"Avoid politics, but have right folks vouch for your work"/"Become an adept politician".

> Politics is the art of making other people want the things that you want. I would say tactical negotiation and leveraging personal connect is healthy, but manipulation for personal gains at the cost of a larger good is what is my definition of "politics". I have seen couple of managers in my career who, while were poor managers based on employee voice surveys in the company, ended up with large charters due to bein…

Sure, that's totally fair, but let's step back for a second. Let's say there's you, who's got the company's best interests at heart and a great technical/product direction. Then there's Steve. Steve is rubbing backs, in it for himself, but in the pocket of everyone who matters. Who's gonna win? Sadly, it's Steve. Not playing politics is a great way to lose at politics because you're going to get beaten by the first person who is.

Now, if you're a good politician with the best interests of the company at heart and the technical skills to deliver, the math is different, and the sky's the limit for you :)

Re: Show HN: A Senior Engineer's CheckList

#80
post #53

About this one: > Respect code and systems that came before you. There are reasons for every code and every guard that exists in production Sometimes there's bad code in prod, or code that doesn't need to exist anymore. You should try to understand when something is there for a good reason versus a bad reason. Cut out the bad code, keep the good code. I've seen a lot of cases where people assume that current code is…

I think the main thrust is respect the code and understand why it was there. Don't start with the possible initial feeling that a particular piece of code or guard is not needed. If you do find that it's not needed, remove it or fix it.

This is very similar to Joel Spolsky's advice that you should never just chuck code out and and start from scratch.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Post reply on HN