Explore Asking Great Questions on Taro

Every time, when my manager asked me to do some changes to the repository that is totally new to me. I became scared.

I prefer to do research by myself first. But I got lost in the new repo by reading file by file, and don't get the clarity.

So I ask the repository owner to provide documentation, mostly they don't maintain documentation, and even if they do, it is not updated or it involves a lot of detailed feature-wise documentation, which is usually not relevant to my requirement.

Then, I call the POC of that repo, but I couldn't figure out what is the right question to ask in the first call. Over time, I ping him asking questions whenever I face hurdles while achieving the requirements.

Sometimes, I put a debugger or logs to understand the flow of code.

The above processes took a lot of my time.

What is your suggestion to get clarity in the new repo such that I can complete my requirements in less time?

I asked this question on chatGPT, nothing proper not found. I need your help guys, currently I am interviewing with some companies which their Glassdoor reviews are really low and there are pretty bad reviews in terms of culture and engineering. Just wondering what is important things can I ask them to get know more about that, or is there any technique that bring this kind topics during the interview?

Finding a solution is one thing but you don’t understand it unless you can communicate it and others can understand it too

This becomes specially important when you are blocked and adds an extra layer of complexity when finding a solution can already be a challenge

What good practises can one apply to get better at this?

I'm still navigating a career switch to SWE, and I tend to get pretty overwhelmed when looking at code. I already ask a lot of questions, and I want to be more self-sufficient because my full-stack team members are pretty busy. (They are all kind and would all be willing to to take some time out of their day.)

How can I get faster at reading code on my own while balancing a team transition? I'm at the point where I understand the high-level purpose of parts of our codebase but little as to how the moving pieces all fit together.

While I understand that there is likely no magic threshold to determine the point at one needs to ask for codebase navigation guidance, a good rule of thumb would be helpful when possible.

Recently I completed my first-ever proof of concept (POC). I got positive feedback, but I think it's because the manager understands that I am doing this independently for the first time. After giving credit for my work, one senior member broke down the task into smaller pieces with step-by-step technical sources (from blogs), which made my life much easier. Now when I am re-evaluating this now, I observe the following:

• I tried not to bother senior/TL for help since I didn't want to interrupt their sprint commitment. Even though they are supportive, I couldn't help but feel nervous because I am the engineer with the least experience (i.e., others are either senior or principal level or the same level but have a much broader knowledge domain).
• After receiving the breakdown plan with the easy-to-follow resources, I am much more comfortable tackling the tasks. If possible, I very much want to be able to break down a bigger POC into smaller pieces and tackle each in order.

Since it's likely to have more POC shortly, and I am sure I will face this situation, I want to overcome the nerve and ask the right amount of questions (not too much, but good enough to unblock me) during growth along the POC task.

Thanks ahead for your sharing!

I will be moving to a new team soon. Is it recommended to ask for feedback from my old team before moving out.

I have good relationship with my team and I want to leverage them to know more about my overall contribution as a team player and engineer.

What is the best way to do that ? What type of questions I can ask ?

I want to avoid falling into same mistakes and grow faster in my new team.

I came into my role with an advanced degree, so I started out as a mid-level engineer. However, I still need to be able to ask questions as I've never worked as an engineer before. I've seen all the Taro content around asking questions, but my manager has drilled in since a few months into this role that expectations are that I function independently, unblock myself, and don't take up much of others' time by asking questions. That it would count against me in performance reviews (versus for me if I help others with their questions).

Given the current job market, I don't know where else to go, but this environment leaves me pretty exasperated. Is it normal in other companies to go to more senior engineers with help getting unblocked? Are questions only really around code, or is it normal to ask for help debugging a feature/bug/test? I worry about becoming a senior with the expectation to be independent and help others when I myself have never received guidance to grow to that level properly.

I recently started at my new gig as a remote tech lead. While I am on the West Coast, most of my team is either on the East Coast or in Europe (+11 hrs). Meetings start at around 7 AM PT and go on until 11:30 AM PT!

Here is my challenge: I am a morning person & like to do more deep & undistracted work during the morning hours (Coding / Reading / Writing) . Screen time in the mornings usually drain me out & my productivity dips post multiple zoom / G-meet calls. What are your thoughts on how could I balance my sacred morning hour time between meetings & impactful work?

Thanks!

What is a good way to ask questions in a domain where you lack knowledge? How do you make a question a high effort question when you know relatively little about a topic? Sometimes you're put in a situation where you don't really know the fundamentals. How do you navigate this landscape and ask questions of higher quality? I feel like the more that I learn about a certain topic, the better I get at at asking questions in this area. However, I don't really have a great framework on asking questions when I'm starting out in a new field, so what could one do in these cases?

Currently working full time as an Android Developer but also running a small consulting gig on the side. Main reason at the time was to have another income stream.

Now I am torn between keeping both jobs, quiting the full time and going all in on my company or dropping my company.

For me personally it is a difficult choice because I am driven to achieve what my mind sets out to do but lately I have not been enjoying work like I used to. In the end the decision is mine to make but I would love some guidance.

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?

Hello! 👋🏼

I finished my first JIRA ticket today and I was assigned another ticket, but this ticket feels different…its requirements are significantly more vague.

I understand at a high-level what the requirements for this task are:

1. check a folder for new files every x min
2. copy new files to another folder
3. keep track of copied files

These are examples of some the questions I had, however they feel too low-level for the analysis stage.

• what file types can I expect?
• should the frequency be editable?
• how should the program handle a job run that takes > x minutes?

So, my question is this: what high-level questions can I ask to further demystify these vague requirements and future requirements?

I have my 1:1 catch up call scheduled with my manager soon, this is the first 1:1 / call I'll be having with him since I met him in the interview. What are some of the good questions I can ask w.r.t to the team and the work that I'll be doing? He had taken my System Design interview and there he went on to talk about the team for 15 mins where we discussed about the team work, team size, on call structure, wlb etc. One important point which I feel is that I won't be joining the team immediately, there's still 3 months time.

Fear/stomach-turning when I think about asking people for help (especially in public channels) has been a major blocker for me as a junior engineer.