HACKER Q&A
📣 curious_dev

Things to do/don't in the first week and the first month in a new job?


Looking for answers from the more experienced people here who have changed jobs multiple times in their career and were able to start making impact quickly in a new team, specially SWEs.


  👤 softwaredoug Accepted Answer ✓
Don’t come in with too many ideas and no context on the org.

Don’t try to do too much, you’re new, onboarding takes time.

Don't pass judgment on the team, it’s practices, it’s work, etc until you can establish some empathy and context for why/how things got there.

Do listen a lot. But really do this always anyway as your default mode of communicating.

Do make small improvements to the onboarding process. It’s an easy way to ship in your first week

Do find ways to make small, but meaningful improvements.

Do have a “beginners mindset”[1] regardless of what you’ve accomplished in the past.

Do appreciate what is different about this place, it’s culture, working norms, values, etc - esp the unspoken ones that might be taken for granted. Write those down for future new people.

Do schedule 1-1s with your lead and teammates. Maybe your skiplevel. Connect with them as people.

Do be open and growth oriented. Expect to not like something at first, but give it time to let it grow on you and gain context before passing judgment.

Do collaborate a lot. Pairing is caring when you’re new. Esp when remote, building together can help grow your relationship with teammates. (They should want to collaborate to help onboard you)

Do demo a lot, but make it about what the team did together in your collaboration, not about you.

Do couch your observations and ideas as questions, not strong assertions or pronouncements. It lets you probe the issue. Instead of “WE SHOULD TEST WITH PYTEST!!!” Maybe try “I notice we used pythons built in unit testing, just curious if there’s history there on how that came to be?”

Do understand how your team is measured and incentivized.

1 - https://en.m.wikipedia.org/wiki/Shoshin


👤 kingkongjaffa
Ask questions. write everything down.

try to figure out the codebase, find the docs and the person who maintains them.

try to figure out who wrote/maintains what part so you know who to ask for help.

Figure out if you should try to get into the middle/meat of the codebase or if you should start working on the edges. (Architecture/culture dependent).

Schedule 20-30min intro/coffee call with anyone who will accept.


👤 AnimalMuppet
Listen. A lot. Even if you think something they're doing is stupid, keep listening. Don't rush to judgment.


👤 loa_in_
My $0.01: don't tell anyone if you find a way to automate something (if it's not in your job description). If you do automate something away (of your job), don't tell anyone you don't trust very much.