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

Ask HN: How to approach first days on a new job as a senior engineer?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Ask HN: How to approach first days on a new job as a senior engineer?

#51

Post by verelo »

valbaca wrote: post #46
verelo wrote: post #41

Earlier quoted context omitted.

This is an amazing response. In particular this. >> "Disrespect current processes. What you call “legacy code” was done for a reason, is generating revenue, solving real world problems, and the reason you have a job" I'd summarize and simplify your "What to do" by simply saying: Be curious but not annoying. We have an extremely background (3x Founder/CTO + A bunch of other things). The largest issue I would find with…

I'm curious what word was missing from this > We have an extremely ??? background (3x Founder/CTO + A bunch of other things).

lol...weird brain fart: "similar" was the word i was hunting for

Re: Ask HN: How to approach first days on a new job as a senior engineer?

#53

Post by lmeyerov »

ApolloFortyNine wrote: post #40
lmeyerov wrote: post #20

Assuming not management track: - Make a token commit day 1 or 2 to show you can and will deliver, even if just docs. Ensure you can go end-to-end on a real code PR week 1, even if a trivial one. Identify which area of code is most important for you to learn, vs not learn, and focus there. - Get agreement on week 1 / month 1 / q1 goal for you+team+co with your direct peers, manager, skip level. Assuming a startup, als…

Unless you live somewhere that has some form of probation, a token commit day 1 or 2 seems pretty meaningless. Everyone involved will see it instantly as that, a token commit. Making an effort to learn the business (essentially the 'why' of your area at the company) is valuable of course.

Yep very contextual as replies show!

Ex: I'd not expect a code commit to happen at a bank or most gov places, eg, you might be waiting for clearance for months to even see the real data!

There are many ways to set the tone, and code does speak. Great interns, senior engineers, PhDs, etc I have worked with have managed to get bits flowing the first day and week in great teams & companies environments I've worked with, and it's a pretty sure fire way to set the tone & build team trust. Multiple people often start at the same time, and everyone sees the difference. I've seen other folks do other things too, so it's not the only way. Whatever way, what you do, and not do, is a decision.

Other folks here are right to point out that not all Senior (Software) Engineers contribute code. Ex: The more senior you go, you get more differentiated titles than a generic senior eng, and part of that is splitting between management vs engineering. What an effective staff eng at Facebook vs Microsoft vs openai does on week 1 is an interesting question -- at an early stage startup, they would already be ramping up to deliver, so both the soft & hard side.

Re: Ask HN: How to approach first days on a new job as a senior engineer?

#54

Post by lmeyerov »

switchbak wrote: post #25
lmeyerov wrote: post #20

Assuming not management track: - Make a token commit day 1 or 2 to show you can and will deliver, even if just docs. Ensure you can go end-to-end on a real code PR week 1, even if a trivial one. Identify which area of code is most important for you to learn, vs not learn, and focus there. - Get agreement on week 1 / month 1 / q1 goal for you+team+co with your direct peers, manager, skip level. Assuming a startup, als…

"earned & lived experienced" - what is an earned experience? How does that differ from a lived experience?

Yeah sorry -- I mean paid dues in diff ways, such as study and practice (earned), and having seen the realities of the business / software / last attempts (lived).

Re: Ask HN: How to approach first days on a new job as a senior engineer?

#55

Post by wojciii »

jkingsman wrote: post #6

Keep lab notes! I keep detailed daily notes of what I've learned, code I've run, what my todo list is, etc. in markdown. Getting in the daily habit helps you not go "eh I don't need notes for this" and is a GODSEND come review time when you need to write a self eval. When I onboarded at a larger (10k people) company, I asked my manager for people who did a similar role to me across the company and asked for a fifteen…

Notes are important for me.. I write a (private) timestamped diary which I can go back to and find out why I did something at a specific time when asked about it.

I work as a consultant so I need to do this when requested, but it gives me a quick way to remember details that I would otherwise forget and also quicky get to speed after a vacation or weekend by reading my notes and TODOs from the previous week.

Re: Ask HN: How to approach first days on a new job as a senior engineer?

#56

Post by wojciii »

ge96 wrote: post #22
lmeyerov wrote: post #20

Assuming not management track: - Make a token commit day 1 or 2 to show you can and will deliver, even if just docs. Ensure you can go end-to-end on a real code PR week 1, even if a trivial one. Identify which area of code is most important for you to learn, vs not learn, and focus there. - Get agreement on week 1 / month 1 / q1 goal for you+team+co with your direct peers, manager, skip level. Assuming a startup, als…

Man I just joined a new company, super disorganized like no ticketing, don't know what I'm supposed to do/when. I think my manager is new. Oh well I'm grateful for the job. I at least have self-awareness (like someone else mentioned below) about not sh*tting on everything existing. No PRs, No tests, Code barely works from master, no docs how to get started, that's the kind of environment I'm in so it's not like it's…

Sounds like an environment where you should not ask for permission and just implement whatever you need to be efficient. Ask for forgiveness instead.

I would implement the bare minimum of what I need (probably unit tests, integration tests, branching, some kind of DevOps, wiki, auto-generated testspec/test report).

Re: Ask HN: How to approach first days on a new job as a senior engineer?

#57

Post by codingdave »

scarface_74 wrote: post #10

Context: I was an early strategic technical hire by a director/manager/CTO 3 times to help execute process changes and lead new initiatives healthcare SaaS companies between 2014-2020 and then started working in strategic cloud consulting since then where I am brought in to get developer, operations and the “business” to be better aligned and/or to lead new initiatives. I’m currently a “staff software architect” at a…

Ask the flip side during #4 as well - what do they love about the work, that would bring great disappointment if it were to change?

Aside from getting more info, it keeps the conversation positive. Nothing brings fear into an organization like a new leader who calls everyone into 1:1s and only digs into the negative.

Re: Ask HN: How to approach first days on a new job as a senior engineer?

#58

Post by _kb »

scarface_74 wrote: post #10

Context: I was an early strategic technical hire by a director/manager/CTO 3 times to help execute process changes and lead new initiatives healthcare SaaS companies between 2014-2020 and then started working in strategic cloud consulting since then where I am brought in to get developer, operations and the “business” to be better aligned and/or to lead new initiatives. I’m currently a “staff software architect” at a…

This is great advice. The first x days change freeze on anything you'd like to implement / 'improve' is crucial.

Definitely note down everything that you think is a good idea. By time you reach those first few months and you have context you will likely cross most out. See the concept of "Chesterton's fence" for more.

Re: Ask HN: How to approach first days on a new job as a senior engineer?

#59

Post by deanmoriarty »

It is surprising that this still happens, but I’ve had senior engineers (L6-L7 from FAANG) join my teams (multiple examples, different companies) and in the first couple days make extremely superficial but strong arguments on how the architecture of a system should be completely revisited, and how libraries that have been in production for years should just be rewritten from scratch asap.

In virtually all cases the suggestion was extremely naive and coming from a lack of understanding of all the requirements. This did not come from a curious angle “wondering if we could do X?”, it was always based on some ground truth they knew better.

Very calmly, you start explaining to them all the key requirements that they just missed in their grand vision. Upon hearing those, some will decide to double down and come up, on the spot, with increasingly complex and arcane evolutions of their initial proposal (this is always very comical, and painful to witness), while others will quickly get the message and basically say “oh sorry, seems like I lack a lot of context, please ignore”.

And let’s not even talk about their first code reviews.

I truly don’t know what goes in someone’s head when they decide, shortly after joining, to dismiss years of work of a competent team who has objectively solved problems for the business.

Re: Ask HN: How to approach first days on a new job as a senior engineer?

#60

Post by soulofmischief »

rolothrow wrote: post #42
jkingsman wrote: post #6

Keep lab notes! I keep detailed daily notes of what I've learned, code I've run, what my todo list is, etc. in markdown. Getting in the daily habit helps you not go "eh I don't need notes for this" and is a GODSEND come review time when you need to write a self eval. When I onboarded at a larger (10k people) company, I asked my manager for people who did a similar role to me across the company and asked for a fifteen…

On the topic of notes: are there any standard formats you prefer: I've been guilty in the past of ending up with a chaotic endless MD and I'd like a bit more process

I recommend Logseq if you're taking notes on a computer. Takes a moment to wrap your head around an outliner if you haven't used one, but after a short while notes will fly from your fingertips.

Being able to quickly jot things down and later revisit and expand them is crucial. Logseq also gives you a fresh journal for each day, and you can make and reference your own topic-specific pages as well.

Post reply on HN