Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A Senior Engineer's CheckList

news.ycombinator.com

Post reply on HN
Print view View original

141–150 of 155 posts

Re: Show HN: A Senior Engineer's CheckList

#141

Post by rsashwin »

littleblah wrote: post #40
rsashwin wrote: post #36

I like the css and theme of your website. Did you design it yourself or is there a theme of sorts which you adopted?

Thanks. Its "even" theme on hugo. https://themes.gohugo.io/hugo-theme-even/

Thanks for sharing! Really appreciate it.

Re: Show HN: A Senior Engineer's CheckList

#143

Post by scaryclam »

LandR wrote: post #72
xxpor wrote: 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'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.

At my current company we ask even juniors to get involved. Interviews are in pairs, with at least one senior person in that pair, so we can make sure each interview is as fair as possible. IMO everyone can have a valid view, and since we could well be looking for their next team mate I'd prefer to know that it's not just my opinion that gets heard. It's been working pretty well so far, and given people more experience in hiring that I hope helps them later in their careers.

Re: Show HN: A Senior Engineer's CheckList

#144

Post by daveslash »

LandR wrote: post #73
notTyler wrote: post #41

'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 sure it depends on your organization, and with large orgs maybe even your particular subdivision. That said, I can sympathize. I'm involved in the interviewing process of my niche in the org and try my best to hire quality candidates, but I can say that a non-trivial amount of devs are hired into the org without demonstrating any ability to code.

I think even a simple fizz-buzz can be a good litmus test. "I see here that you put JavaScript on your resume - good, we need that here. Let's open a console window in Chrome and do FizzBuzz". I've honestly gotten blank stares - developers who don't even know where to start.

[Edit: Spelling]

Re: Show HN: A Senior Engineer's CheckList

#145

Post by Urazali2719 »

### Keybase proof

I hereby claim:

  * I am urazali2719 on github.
  * I am urazali2719 (https://keybase.io/urazali2719) on keybase.
  * I have a public key ASADC8BhFtXLnUIAXTc2ZWalDt7IjsKRYUK6bcEbNZNN3wo
To claim this, I am signing this object:

```json { "body": { "key": { "eldest_kid": "0120030bc06116d5cb9d42005d37366566a50edec88ec2916142ba6dc11b35934ddf0a", "host": "keybase.io", "kid": "0120030bc06116d5cb9d42005d37366566a50edec88ec2916142ba6dc11b35934ddf0a", "uid": "a7384b781017a51bd2850438b486e419", "username": "urazali2719" }, "merkle_root": { "ctime": 1568063008, "hash": "55e2a1aca29a97218ab28315d1079e1336b99b3aed46b60181b88198d0fad93587538e062da852f70b10e9b333add4f3ef9e5cd0c85b6633951ed0917725bf6b", "hash_meta": "f57d9437e56e0706bcd46bb32c2515003b1df484ae7940a087e12d2f919c2ccc", "seqno": 6255300 }, "service": { "entropy": "pQ1KgMrybqclACOooqMs605+", "name": "github", "username": "urazali2719" }, "type": "web_service_binding", "version": 2 }, "client": { "name": "keybase.io go client", "version": "4.4.0" }, "ctime": 1568063014, "expire_in": 504576000, "prev": "dcbca968d387888c4ab3f37e1d7d6f078287b7b24ee018c5b908da217b211454", "seqno": 16, "tag": "signature" } ```

with the key [ASADC8BhFtXLnUIAXTc2ZWalDt7IjsKRYUK6bcEbNZNN3wo](https://keybase.io/urazali2719), yielding the signature:

``` hKRib2R5hqhkZXRhY2hlZMOpaGFzaF90eXBlCqNrZXnEIwEgAwvAYRbVy51CAF03NmVmpQ7eyI7CkWFCum3BGzWTTd8Kp3BheWxvYWTESpcCEMQg3LypaNOHiIxKs/N+HX1vB4KHt7JO4BjFuQjaIXshFFTEIOLvq0969sHy7qFboEd6fzJ3WvqppZhidrhBsa3cr/jFAgHCo3NpZ8RAo2qBHI7Uq5VzjyxJlJPafMcPx0Fhpe42vS7zIPV+hSCzuUTXcTntC+p6mLm0d+sBEOHvWX0fR9MLaomu65OuCKhzaWdfdHlwZSCkaGFzaIKkdHlwZQildmFsdWXEIOcZ1awz/uX7SpgEXR1NQxYUJ/3T35vm+UTgrF9wE68Eo3RhZ80CAqd2ZXJzaW9uAQ==

```

And finally, I am proving ownership of the github account by posting this as a gist.

### My publicly-auditable identity:

https://keybase.io/urazali2719

### From the command line:

Consider the [keybase command line program](https://keybase.io/download).

```bash # look me up keybase id urazali2719 ```

Re: Show HN: A Senior Engineer's CheckList

#148

Post by arendtio »

mgkimsal wrote: post #96
dbmikus wrote: 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…

The opposite can happen. Took over a system in Aug '18 with someone else. Previous 'senior engineer' had left after a year to go be a CTO someplace else. Everything seemed wrong - bad smells everywhere, spidey-sense a-tinging every day. In October, we found that code put in place had been losing data since April - we had 6 months of pure data loss. Data that people assumed was 'working' because ... they hit a button…

I think you are missing the point. Respecting systems doesn't mean 'not touching' or 'working around' existing systems. It just means 'understand it, before you change/rewrite it'. Otherwise, your rewrite might be even worse.

I have seen people proclaiming a rewrite with a newer technology would be a good idea who didn't have the slightest clue about the system they were trying to replace (except that it was build with some outdated technology) and I am 85% sure, that their rewrite would have been worse. When I confronted them with my claims, they gave up quickly.

As a Senior Engineer, you should know what you are doing. If you see obviously bad code, thinking about a rewrite is no sin. Just try to understand what caused the current system to look like it does.

Re: Show HN: A Senior Engineer's CheckList

#149

Post by arendtio »

wry_discontent wrote: post #113

> [Reminder] One-on-one usually is not a status meeting I have never had a job where my one on ones didn't devolve into status meetings and chitchat. What the hell am I supposed to talk about?

Recently, I came across this list:

https://jasonevanish.com/2014/05/29/101-questions-to-ask-in-...

Haven't tried it yet, but might help you to change your one-on-ones.

Re: Show HN: A Senior Engineer's CheckList

#150

Post by littleblah »

Flimm wrote: post #137

Here is a clickable list of what the OP posted, for the lazy: 1. https://littleblah.com/post/2019-09-01-senior-engineer-check... 2. https://medium.com/@littleblah/my-top-25-items-in-a-senior-e... 3. https://github.com/littleblah/senior-engineer-checklist

Thanks. Somehow I failed to create clickable links :(
Post reply on HN