Being a sceptical ct, I would say that all of these items in the first list are shaky at best.
"All that matters is profit" is how we end up with melting ice caps!
Show HN: A Senior Engineer's CheckList
81–90 of 155 posts
Re: Show HN: A Senior Engineer's CheckList
#82'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).
> What is high? Unless you've defined what that means, and everyone involved understands and agrees what that means, it's just a word.
Yes, this is the right question. I think the reason there is no generic definition is because it's subjective. The most generally applicable part of this is the differences in hiring practices at large-scale vs tiny-scale (there was an article on HN previously explaining this particular area):
The main points were google-scale can afford high salaries and can afford to cut out good candidates from the hiring process in the name of automation, so easy to automate and standardise empirical testing works for them, but not for small-scale, because you wont be able to afford the same candidate. Instead small-scale either hire for the people who fall through the cracks of large corporate structures or they hire for potential.
In answer to your question, this difference affects (or should affect) the qualities being measured... for large scale it's whatever the job requirements are, measured there and then; for small-scale it's the potential for whatever the job requirements are e.g enthusiasm, drive, domain specific interest. That's just one dimension of a company, there are all kinds of other aspects that will also affect qualitative measurement of a candidate.
Re: Show HN: A Senior Engineer's CheckList
#83About 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.
It's essentially the Chesterton's Fence principle.
Re: Show HN: A Senior Engineer's CheckList
#84Earlier quoted context omitted.
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-...
Yup. That was my inspiration, and sadly, I have been on the side as well where things started from scratch, and ended up blowing up couple of months later.
Re: Show HN: A Senior Engineer's CheckList
#85'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 se…
Are you having problems with the junior developers that are getting hired?
Re: Show HN: A Senior Engineer's CheckList
#86'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 se…
I’m seeing the opposite in DC. Our recent “junior” candidates have been very impressive. I can see the affects of competition being played out. And, especially the female candidates - just outstanding.
Re: Show HN: A Senior Engineer's CheckList
#87'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).
What defines a high bar, at BT our team had a DBA whose first boss was Dijkstra (yes that one) we was the unofficial database GURU for the entire engineering centre.
But we also had some one who was even more of a GURU IBM used to ask him for advice on large Mainframe database problems.
Re: Show HN: A Senior Engineer's CheckList
#88It's a (thoughtful) list for the "senior engineer in 500+ heads company". If you work for a small startup (where you'll be forced to be "senior engineer" if you like it or not), you'll have no "manager", "peers", "projects", "hiring", "mentoring", "networking", and so 95% of the list items immediately pop.
I worked at a five person startup, and I had all of those.
Re: Show HN: A Senior Engineer's CheckList
#89'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.
Why most developers never have any HR/IR training or do this in their day to day Job.