Editor's Choice Q&A and Videos

I am been working as a Senior software engineer for quite some time now. To move to the Staff level, one feedback/pointer I got was to start developing opinions on how to do certain things. When people start respecting your opinions, they start to see you as a leader.

The problem I have is, in many cases, I don't have enough relevant experience for the problem at hand. Also, I find, that in discussions I am listening more than I am speaking. Having no opinions, and finding it hard to express opinions for fear of being judged and losing respect in case my opinion is wrong, are the problems I am facing.

Is there any advice on how to develop these skills?

I have often found platform teams to be quite "tech-heavy" rather than being driven solely by business. On the other hand, it is easier to convey impact for product teams for the metrics that the org cares about much more.

If I am trying to move from Mid Level to Senior Level i.e. Senior Software Engineer to Tech Lead level in my org, what kind of teams should I target?

Does choosing a certain one help you in fast-tracking your career growth?

During session, Rahul mentioned only a few projects are important. I would love to get some concrete examples from Rahul or others on what that looks like. This is my very first question that I am posting in Taro forum. Thank you for the encouragement Alex. Looking forward to everyone's answers.

I've gotten feedback that I'm more on the quiet side and that I could be more active in meetings. However, I feel like I don't have much to add when it comes to meetings. I want to say something that's insightful and adds value to the conversation, but I'm unsure how to come up with that level of material, especially on-the-spot during the meeting. How do I figure out what to say?

I am mentoring juniors for the last few weeks. In the past, I've been mentoring people with some professional experience but this colleague doesn't have any. Now, after these few weeks I am wondering:

1. How much time should I spend helping them? Currently, I have to spend 2-3 hours for person per day otherwise they will be blocked for days. Even though I am trying to explain that they can ask other colleagues as well, they are not asking anyone else.
2. How can I be sure what are they suppose to know and what's not? For me, I have my own understanding of what they should know but I know for others may differ. In my country the juniors must be part of an academy before applying for a job. I know what they learn there, so I know what hthey should know and what not. Now, after these few weeks I realize they have gaps which they shouln't have. On the other hand, the academy is typically more than an year and it makes sense many things to be forgetten with the time.
3. How can I measure properly their performance since they are just starting? What is a normal performance?
4. How deep should I go in explanation of his questions? I believe this is where the high quality questions will help them, but I believe they have a lot of gaps to make a quality question and give the proper context.
5. How can I help them to improve their questions instead of having to explain for hours one topic and then another, etc?
6. When should I say I give up on him? I really want to try everything before giving up.
7. How to stay less emotional when explaining the same things for hours to the same person?
8. How can I help them to understand me better? Sometimes, no matter how am I explaining specific case/topic and no matter what examples, nothing helps.

I think the colleagues are really motivated and this is one of the reasons I want to help them. I want to be sure I did everything I can.

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?

In Alex's case, he met Rahul at Meta and now they're cofounders. How can I build up such deep relationships with other people at Google or any future company I work at?

I recently found myself in a fortunate yet challenging situation due to a layoff. I have been granted a two-months period plus optional month(s) in lieu of severance, to secure my next job as I need a visa sponsorship. I aim to land a senior mobile developer role here in the UK, in any non-big tech company (tier 3/4). Considering the urgency of securing a visa, I am open to exploring any roles with sponsorship.

To make the most of this time, here is how I am spending my time so far, I would appreciate any input and suggestions to make the most out of this situation.

1. Dedicate 2 hours daily to solving easy LeetCode problems - some tier 3/4 companies do ask some easy/medium questions

2. Spend 2 hours daily applying for jobs on LinkedIn, Dm'ng connections, seeking referrals etc

3. 2/3 hours Develop a side mobile app project to practice and familiarize with recent patterns - most likely needed to succeed in take-home tests.

4. Behaviour and system design - study and practice only when I have those rounds scheduled.

I wonder if there are any other aspects I should optimize for during this period. Are there any specific areas or resources you recommend focusing on to maximize my chances of success?

I'm a Computer Science student, and I'm currently looking for software engineering internships. I graduate in ~1 year or so, so I'm interested in how interviews work for full-time entry-level positions as well.

Companies are so different and ask various questions - How can you predict with decent accuracy what's going to be on their interviews? Also are behavioral questions in a tech interview generally the same for most companies?

I'm imagining a 2x2 matrix where one side has work-hard/not work-hard and the other has advance/don't-advance in career.

I think it's safe to say that one box has very few people in it: not work-hard and advance. I'm sure there are people who don't work-hard and get promoted, but these people must have something that gets them promoted such as great communication skills and the ability to sell themselves, so at least in that sense, they are unique and productive.

I would think most software engineers would fall into the work-hard/don't-advance block because they focus on the wrong things. In my view, you either want to be in the not-work-hard/don't-advance block or the work-hard/advance block, since the don't work-hard/advance block is not available for most people.

My question is, is the way to get to those 2 blocks effectively the same in terms of the skill sets needed, and moving between them purely a matter of quantity or effort? That is, in order to get by at a job where I would be content to just do the necessary work and then go home, I need to learn to be productive in a short amount of time, and then if I decide that I actually do want to advance, I only need to ramp up on the time or effort I put into applying those fundamental skills?

Hopefully this question makes sense.

Thanks!

Came across on CSCQ where the original poster asks about what these missing essential skills. One reply had me wondering, how I can actually learn these points:

• How to write things in a way that other people really understand what you're saying.
• How to structure code so that you can come back to it in 2 years and understand it.
• How to show off the work you've done.
• How much testing is the right amount, and not too much or too little.

Hi Taro - just wanted to say thank you for the .  I was wondering if you could share with the Taro community your thoughts on how managers evaluate their employees in detail (you mentioned some things like internal tools that one could go and see how many PRs, discussions, comments someone had in Github/JIRA and who all were at the top of that baseline followed by the bottom rankers; so I would like more specifics if possible).

Although no one likes it, it would be good to understand how "stack ranking" works at FAANG - and how some managers evaluate on this criteria, despite it being a practice that sucks. In this way I can just be more sure I'm hitting a baseline - even if it's invisible because I can take daily steps to work on my own visibility and perceived performance.

I feel like the biggest challenge right now is getting critical feedback from a manager / org (and it sounds like some companies in the FAANG space are pretty awful about it).  E.g. I read about a Redditor who got let go without much notice because they weren't up to par (decided by a skip level manager) in terms of their code and daily output (while the direct manager and everyone else had been communicating often that this employee's performance was great). But this goes back to the idea that 'great' is 'average' lately, and it's way harder to hit exceeds and greatly exceeds on performance.

Thank you in advance!