Explore Onboarding on Taro

I've been struggling with onboarding at my new job.

I'm part of a new team; my only other teammate recently joined. Many related docs are not in English & the translation is weird & confusing often. This makes revamping up independently super hard for me. I try to find that concept in an English doc from any other team, and that's my way of understanding something. But it puts a lot of overhead because I basically now try to understand the work of a lot of related teams too. And often it is much more time for me.

My manager has a lot of people report to her. I had a 1-on-1, and I explained the situation. She asked me to ping her for help. I often have stupid questions, and I feel weird asking her directly. So I asked her to assign me an onboarding buddy from the related team. But from her reply, it seemed like I should talk to everyone on the team & figure it out. I think she wants me to be more independent.

Now I ping people in my team or close teams to ask for help. I have found most or nearly all people to be super-helpful, and they relate to being in the same situation once. But I feel guilty about asking people for help. I feel it doesn't do much for them. As with most, I don't have a team meeting where I could thank them & their/our manager would notice it.

How should I better navigate this situation?

I'm on a team with many new SDE 1s, and I'm trying to get them up to speed. However talking with all of them takes a lot of time, and it's affecting my velocity with project execution. My manager suggested that I set up office hours. Does that idea make sense and are there any other ways to make this all more efficient?

My question is when should I reach out to help someone. If someone new joins, and if it is clear that task might be difficult for person, or there is some context needed etc, and they fail to ask, should you help them? Reaching out early and helping might be hampering their own learning, also at risk of hurting someone's ego. But If I am in other person's shoes, I would appreciate all help so what is right balance here?

Also, should you helping be more visible or private? If it is public, other people can add extra context as they like, but maybe in private conversations, person can ask more follow up question, assuming they are afraid to ask dumb questions. To be more specifically, by public I mean team channel in slack and private would one-one chat.

I just started working at a new company. I am still going over the general onboarding process for all employees.

How should I go about introducing myself to the team & manager? Should I ping them on chat to say Hi & asking them to add me to the meetings? My whole team has about 16 members.

Thanks in advance!

Should I be focusing initially on quick wins or higher-impact, high-priority projects that could potentially take longer?

We have a sprint planning session every two weeks where epic owners create tickets and they are presented to people. Whoever is interested in whatever tickets, they assign it to themselves.

Everyone has 10 story points worth of tasks where 1 story point is one day’s work. When these tickets are created, the creator assigns an estimated story point value based on their judgement of the complexity of the ticket.

But sometimes, the task can be more complex than estimated and it might spill over.

I tend to take 10 points worth of tasks but definitely 1/2 points get spilled over to the next sprint because of unplanned delays while finishing them and my own inefficiency/ procrastination.

I have been given the feedback that I tend to overcommit and it would be better if I brought it up earlier in daily stand ups in case some tasks are taking more time than usual. This will enable others to pick up some other task on my board in case they are done with theirs.

I do see my inability to complete the 10 points as a personal failure even if no one explicitly points it out or cares about it. Most of my team mates tend to get them done though. I am 6 months in the team and the rest have been there for 2-3 years at least. I want to get better at planning and completing my sprint tasks. How do I approach this problem?

Hey guys,

I'd appreciate some advice since I'm having the first month in my new company. So far it seems that many processes are neither formal or automated, and there's also a lot of documentation missing. In one of the tutorials and also in my discussion with Rahul, the advice was to not rush towards suggesting improvements right away. However, in my company I see a lot of room for improvement and I have some ideas on how to make things better. What would be your approach?

I have recently joined a team which works in Go (no frameworks). My team handles multiple backend services ( exposed through REST APIs ) which are like a platform for various other services.

I have picked up the language grammar and have enough understanding to write working code. However, I feel I don't "get" it. I don't understand how to organise the code into a well-defined folder structure and interfaces.

I would like to understand what are some of the good ways to learn a new language. It's been 2 months since I started learning it and feel like I am working with incomplete knowledge. Maybe at 50% level. I know there's no point in understanding all the features of a language but I would like to understand design patterns, best practices and how to write high-quality code.

I really need to be able to ramp up in another month's time.

Majorly need advice on

1. Learning to write high-quality Go code
2. Writing with Dependency Injection in mind
3. Design patterns and low-level system design

My starter project was to migrate a web service to a new API which offers similar functionality. This was intended to be a pretty straightforward migration, mostly renaming + replacing some strings. However, this project took much longer than my manager or I anticipated. How could I have predicted and prevented this?

Hi everyone,

I work for a company that offers online web and mobile apps for US-based customers. As part of a recent re-organization, all mobile, web, and backend engineers have been combined into a single on-call rotation. Even though most of these 20+ engineers (mobile + Web engineers) have not much context about the backend system, my director wants to alleviate the frequent on-call rotation, and he proposes having a healthy size of on-call rotation that uses the "follow the sun" model approach, which involves training engineers in different time zones to have knowledge transfer about the backend system and potential issues. I'm curious to know how I can effectively onboard and train over 20 web and mobile engineers for the on-call rotation while following this model.

The Backend team has compiled a comprehensive support run-book log for each corresponding issue/alert, which shows the severity, priority, and range of the issue. The on-call rotation involves acknowledging alerts and following the steps outlined in the run-book.

Please note that the support run-book is not a 100% comprehensive source of truth since the production system is integrated with multiple 3rd party APIs and systems, and the backend platform serves as middleware for both mobile and web applications. There may be instances where issues are caused by third-party vendors and cannot be solved by the on-call person.

I would love to hear your thoughts and perspectives on this matter. I'm also meeting with my boss for our one-on-one to talk about his idea. This is still an experiment, but would like to get people's perspective. Thank you!

How does it differ from an entry level engineer to the head of engineering level at each of the levels, given the scope grows as well at each level?

• Software Engineer
• Senior Software Engineer
• Tech Lead
• Staff Software Engineer
• Principal Engineer
• Head of Engineering
• Director of Engineering
• Vice President
• CTO

How do each of the levels ensure they are onboarded as quickly as possible to have maximum impact ?

I just joined Target at a Principal level. My manager is spread very thin and wants me to take initiatives and has told me to start networking heavily in the first few weeks. My plan is to create an Onboarding doc and share it with my manager. I'm going to use this doc to manage expectations and use it to review together 3 months down the line. How can I structure this doc? What pieces of information are more relevant/vital for such a doc. Any pointers?

To put this into context, the question refers more to people who have already been at the company for a while, not onboarding engineers.

In my experience working only at startups, almost all learning has been the responsibility of the employee. There is a "spike" period where the engineer is given time to come up to speed, but it has always seemed to me a bit careless for managers to just give someone a list of technologies and say "learn this."

I guess this question is really a proxy for asking: how does FAANG approach "bootcamping" engineers on a new and important stack? Are workshops, training courses, and L&D actually effective? Suppose that I am a senior engineer who wants all the junior engineers in my team to learn how to use AI assist tools like Copilot, how would I approach making this mandatory if I really think it's a technology that's as crucial as git?

1. What are the things you can suggest to reduce the turnaround time for onboarding a new engineer within the team?
2. What are the things that can enable them better?
3. How does this differ based on the stage of their career at which the new hire is in?

I'll be going into Amazon as a senior engineer leading a team of 6-7 engineers. I have some anxiety as I have never worked in a FAANG company before, and I imagine the bar is high. Things are also trickier as I'll be in a different time zone from the rest of the team.

How can I make a stellar first impression after I start?

What concrete things do I say, in a conversation with my manager to "set expectations"?

Do I say something like "I would like to ____ expectations this quarter, is it sufficient to complete project A & project B?"

What if I am new to the company, and unable to contribute meaningfully to a significant project, or there is downtime when no projects are available?

Can I say I'll fix some unknown volume of bugs this quarter?

I'm mid level, new to the company.

I got assigned a chunk of a bigger project owned by a staff level engineer, let's call him X, who has worked on the product for a long time and has a lot of context.

Things that were new to me: the language, the tool chain, product context. The codebase is several years old.

My skip level manager (1 level above my direct manager) once encouraged that I should aim to finish my work in less than 2x the amount of time it would take X to do it (but besides this I received no pressure, or reminder to push for this target from managers).

This was overly ambitious. I worked longer hours and harder than anyone around, including weekends but still could not finish it in 3x the amount of time initially estimated.

The staff engineer overestimated what I can do too. He's very willing to explain but I had a hard time mapping his high level explanation to what happens at the code level.

I could not tell if the standard here is high or the task is too hard. So I leaned towards putting in more effort rather than voicing my concern.

I also did not have a good sense of "are these unknown parts of the code base grok-able with a little bit of time or do they require a lot of time?" to estimate time spent up front.

In the end I got some barebone thing out and he took over. Still took him a couple more weeks to get the thing finished. Along the way he solved some problems I'm sure I have no chance of solving in that timespan.

With this evidence I was sure the task was legitimately too hard for me and was comfortable letting my manager know my opinion.

Back up a little bit, when I started working on the project, my manager knew I could not stick to the original timeline set by the engineer and encouraged me to take my time to learn the codebase. What is puzzling is my manager did not tell the engineer about this unrealistic estimate. The engineer reports to a different manager and has been around way longer than my manager.

Maybe there is some politics going on that I'm not aware of.

Anyway this has been a very stressful experience.

What could I do better? What should I do to mitigate any harm done through this experience?

I am in a new team. I was given a task to provide estimations on a project that involves various components. 2 components were owned by a different team and they were transferred to my team. I have no idea about those components. My senior engineer told me to contact a person to get estimation from someone in a sister team who previously worked on that component. This person gave me estimates as 8 and 10 weeks and didn't get response when I asked if he could share some details. I didn't try to deep dive as these components are again getting transferred to a different team. Nobody in my team has knowledge about these two components.

In the meeting where all teams in the org were present, reviewing the estimates. My senior director asked justification for the estimates, the person who gave me the estimates told I have written the estimates. So I told I don't have details and written the estimates as per this person.

I often get stuck in these type of awkward situations. This is clearly not an onboarding task. How can I deal with these situations and how I could have communicated better?

I have communication issues. Especially in a new team, it takes lot of time to grasp what others are saying. During design discussions and post scrums -

1. When there are varying opinions and I still don't understand how to proceed next, what to say?
2. When there is an alignment and I am not confident if I have understand correctly, what to say?

I'm in bootcamp right now, and many teams are telling me that they have all 3 of these things. My bootcamp mentor says that's not really feasible - There are trade-offs. Am I gullible if I believe these teams at face value?

Starting my first day and I was assigned an onboarding buddy. I was wondering what are some of the main questions I should ask.

Some questions I have asked:

1. Wiki on how to set up dev environment
2. Info about all meetings that I was invited to
3. More info about what our team does?

I'm wondering if there are any other main ones I should be asking or is it just ask as they come along?

I'm pretty new to my company, so I've been asking questions and looking for "hand-holding" to bring myself up to speed. I've been having trouble ramping up though - My velocity hasn't been the best, and I've also gotten feedback that I need to be more independent as a senior engineer.

This leaves me a bit confused - I know that in order to onboard, you need to seek out help aggressively and ask questions, but this seems opposite of the feedback around being more independent. How do I think about these 2 ideas? Should I just be working harder and spending more time figuring things out on my own?

Joining a new team/vertical with the company, I often feel intimidated with the sheer expanse of domain knowledge to be grasped. Given that it takes time, what are the best ways to approach it, so that you are the most effective.

I've heard Alex, Rahul, and other engineers within Taro talk about handholding when joining a new company for all engineers and for newer engineers in general.

What does it mean that an engineer doesn't require handholding anymore? Does this mean the frequency of the questions gets diminished or is it more about needing as much initial help to start tasks or something else entirely?

As I'm starting to join a team soon(and knowing this answer varies by team, level, and company), I'm wondering how long does onboarding take and what does it mean to be fully onboarded within your team

I recently joined my team, and I've been sort of overwhelmed picking up this new tech stack which may be leading to some procrastination. I literally have to Google for everything I want to write. Twitter also has certain in-house technologies, which are pretty challenging to learn. I also started working on a critical project recently with strict deadlines due to headcount shortage.

I saw this as an opportunity to make an impact and am trying my best, but I wish I had more time to get acquainted with the stack. I feel like I lost a few days last week unraveling through the ambiguity and getting context, so I didn't make progress with implementation as much as I wanted to.

I am kinda anxious that I will miss my delivery in the first project which is not setting a right impression. In my experience, there is no excuse for missed delivery and it will treated as a red flag. It's a newer company for me and my org is revenue-generating. Given the phase Twitter is going through, this project is critical and hence I am hesitant to push back on the timelines too.

I also see mid-level and junior engineers on the project moving way faster than me right now, because of their tenure and familiarity with codebase and that can be disheartening.

Lastly, should I be transparent and discuss with my manager if I feel a few days haven't been productive? I don't see any way that will help.

I'm in the onboarding phase. I was assigned a starter task and have been working on it. I haven’t done the work of asking questions on design choices (that part is pending).

I want to be ramped up after a week and am wondering how to spend the time. Should I go in-depth on overall architecture? Or spend time working on the codebase? Or is there something else I should do?

I'm going to be joining Amazon soon and the team I'm on is going from 4/5 people a month ago to I believe 9/10 people (counting me). Our team is going to be comprised of SDE 2's and 1's (I'm an SDE 1).

I'm wondering what's the best way to have the best onboarding experience during this time.

While it will be nice that I will have a decent amount of people who will be in the same boat as me in terms of onboarding, I'm also worried that my manager and more senior teammates won't have as much time for things like 1 on 1s, answering questions, helping me onboard, etc. if they're also helping other people on our team in addition to their own work.

I'll be starting at DoorDash relatively soon, and I was wondering what 1 on 1s I should set up on top of the one with my manager. More specifically, are there meetings I should make recurring vs. 1-time ad-hoc? For context, I'm an iOS engineer.

Hi everyone! I will join Palantir as a Forward Deployed Software Engineer(FDSE). I need advice on tackling the first 2-3 months at the company to gain team respect and trust. I am excited about this opportunity and want to grow but do it efficiently, if that is even a thing😅. Jokes aside, All I want is to have a great career at Palantir.

YOE: over 2.5years(including just over 1year of internship).

Stack Experience: Ruby on Rails, Python, some Java

Current Work: Backend Engineer. Building and maintaining APIs

Hi joining as a senior software engineer in a company where the tech stack is totally different. How to adopt well so that I can do well in the job as well as go to next step.

At my old company, where I worked for many, many years, I wasn’t learning anything new. On my new team, I feel like a junior engineer since everything is new. Because of this, I don’t feel like I’m being taken seriously, even my engineers more junior than me.

I'm trying to stay positive throughout this learning process but would obviously like to build up respect among my team as quickly as possible to start feeling like a heavily valued voice in the room. Any advice on how to do that?

I'm a new engineer at Snap, and my first month here is for onboarding. My team does internal tooling, and I have my first major project already lined up.

My manager said this should take an L4 engineer 1-2 months with a lot of help from the tech lead. This tech lead is a senior engineer pushing for promo.

The stack is a mix of Java, Go, and Python - I'm a back-end engineer on the team. However, I'm transitioning from a field that's pretty far from back-end. I'm wondering how I can make this transition as soon as possible and make sure I onboard well into the team?

My whole team is engaged in a design exercise for the system we will build in subsequent quarters. Since I joined 2 months ago, I don’t feel I’m able to meaningfully contribute. I also feel weak with system design questions during interviews. How can I improve here?

I'm new to my company, so I'm asking questions to bring myself up to speed. However, something I'm wary of is becoming a burden - I assume you don't want to ask the same person every time for help. Any tips on how to figure out who I should ask my question to minimize the chance of this happening? I want to make sure I get along well with my team.

I'm a new staff engineer at Meta, and I know that the bar is high for E6. In particular, an E6 needs to be able to have a large influence on the roadmap and team charter, leading and creating very substantial projects.

All that being said, I want to start crafting and executing that vision as soon as I can to hit the ground running, but I'm unsure on exactly how to do that with Meta's more bottoms-up culture. At my previous job, things were more top-down (i.e. leading with authority, where software engineers work on things because their manager/leadership tells them to). How do I lead the team with this almost opposite engineering culture?

I'm a relatively new engineer at Salesforce (been here just ~4 months), and I'm having trouble clearly understanding my expectations.

What's the ideal ramp-up/onboarding strategy for a Staff engineer at a Big Tech company like Salesforce; in particular, what should the first 3-6 months look like? Are there any specific artifacts you would expect such an engineer to have produced during this time?

There's so many teams to choose from - It can be overwhelming. However, in a company as large as Meta, I'm sure there's huge variance among teams. How can I find one that works for me, particularly when it comes to find E5 scope for promotion?

I have a lot of expectations on my plate, and it can be hard to handle. I'm being put on a project soon, but I do have some spare time here and there. How can I make effective use of this time, and is there anything I should focus on during onboarding in general?

I just joined a new company (7 months of industry experience) and I want to make sure I can come in quickly and make an impact. More specifically, I want to become a quality contributor to the team as soon as I can.

I'm really new as a Google FTE (still doing some logistical onboarding like getting my laptop fully set up), but I want to hit the ground running and start growing at Google as fast as possible. However, I don't know what I don't know - There's a lot to take in, and I'm unsure where is best to focus and allocate my time.

I'm primarily on the back-end, but I've been put on a lot of other stacks. I've worked with www and Bloks and now I need to pick up native Android to debug a deep link issue.

I'm having a hard time with the Android issue. I took a long time just setting up the environment, choosing between VSCode, Android Studio, and OnDemand. I'm now working with adb, which I don't really understand as it's completely new to me. There's not a lot of documentation for my problem area, and it's been rough.

More broadly speaking, how can I do better in these situations and pick up new stacks faster?