Productivity Q&A and Videos

What are the some of the fundamentals to have a strong product sense for a software engineer?

During layoffs many engineers are working in war time mode vs peace time, especially the companies still figuring out Product market fit.

So how can I as an engineer help or challenge product direction, read data insights, do user research, etc where I am not directly involved.

I feel like there is lot going on around user research and the product goal is set but how can I provide valuable input make sure we are heading to right direction and at the same time keep working on right technical things to make product closer to its goal.

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.

What does a typical day working as a software engineer (say mid-level) in FAANG look like? I know there are at least 2 important variables, namely a) the person (how good they are at managing time, how motivated they are, how good their technical and soft skills are, etc.) and b) the team and company they are on.

I'm curious about the nitty-gritty of it, namely how much time is spent coding, how much time in meetings, how much time for breaks and lunch, how common is it to work overtime, etc. I'm looking for both the good and the bad, not the shiny, social-media-friendly videos made by people.

I have read time and again (including from Alex) that many if not most FAANG engineers work evenings and weekends. I just read that today from an ex-Facebook LinkedIn influencer I follow who was talking about his own 1 (unpleasant) year there.

I know my question might be so broad as to be meaningless given the number of engineers and situations there are, but if I can get the day of "Joe or Jane average FAANG engineer" who spends 2-3 years and then leaves, that's what I'm looking for. Not the talented and ambitious few who are able to work long and smart and able to rise up the ranks to staff.

Hey John, I hope you are well. I am really passionate about CS (specifically Software Engineering) and I want to pursue a career in it. But I can't help but be a bit concerned about the future availability of coding jobs due to Al (chatgpt4 and stuff). I understand it's hard to predict how things will be in the next 10-15yrs, but my main concern is that I may be putting in all this hard work for nothing. I'm concerned Al will make my future job(s) obsolete before I even get it. Any thoughts on this?

If you build full "product skills" and use the best tools for the job, which today might be hand coding, but later may be Al guiding, you will probably be fine.

I see....by "product skills" do you mean hard and soft skills?

Software is just a tool to help accomplish something for people many programmers never understood that. Keep your eyes on the delivered value, and don't over focus on the specifics of the tools.

Source:

Saw the above discussion on twitter and it got me thinking with advent of ChatGpt4 and Github Copilot X, what can I do to not get negatively affected by this change.

What are the various skills referred to as "product skills" mentioned in the above discussion and how should we go about developing them?

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!

This is not a typical question for Taro community, but l'm here to vent, and looking for honest advice. I'm a working mother at one of MAANG companies. I am a senior engineer, and currently working in a very competitive team that has very poor work life balance. I love my project and l've been getting good ratings so far and everyone is happy with my performance whether it's my manager, TL, DS, PM or XFN partners, according to their feedback for me during PSC.

However, I've been mentally stressed for months now about meeting the expectations and finishing my work while also meeting my kids expectations and having to deal with their emotions and other stuff, taking them to activities and playdates, ... etc and I don't get much help from my husband due to his larger responsibilities at work. I don't Iike to be an average engineer, as l've been used to excelling in my studies and work, it's a mental thing, perfectionism I believe. Should I just quit my job and look for a more relaxed one, if it exists? I’m at a good point in my career now and have already built very good relationships with everyone, and I’m afraid if I will regret this decision later if I don’t find a good alternative.

I have been repeatedly told that I have a tendency to drop things when doing context switch between multiple tasks. How to manage my tasks effectively so that I can minimize this pattern?

In this , Alex mentioned that his technical documentation stood out because no one wrote docs in that much detail.

Are tech docs mainly for how you plan to accomplish a project and are they useful for junior engineers? If so, how do you write good technical documentation?

Due to unforeseen circumstances from past 6 - 8 months, I've been the Senior most engineer in my team, (I have a total of just ~2.7 YOE). My team consists of ~12 SDE 1s (New Hires) and 2 SDE2s (The other SDE2 being promoted very recently). My manager does a great job filling the role of Senior Engineer which reduces bit of pressure off of me.

However, due to necessity in the team I've ended up being SME in all the services owned by our team. This leads to everyone reaching out to me to help them with their queries, I try to document some of these and add in the Wikis so that it can be easily accessible for others next time. However, when it comes to certain tickets and issues, I end up having to pick that task up myself (Manager does not ask me to, but at same time i know that for someone else the ramp up time required to fix the issue would be too high).

I recently tried to reduce this (2~ months ago), this led to our overall ticket health getting worse and I had to again start looking into them myself and guiding each on-call cycle with right action items for the tickets etc.

This involves me helping them to do the following :-

• Prioritize correct tickets to look into for the on-call cycle.
• A potential fix for the ticket so that they know where to look into.

Due to which it ends up taking 6+ hours weekly to keep this running. I don't really mind doing this; however, I don't feel like this is a scalable solution and would eventually want to slowly scale down from doing this and have my team being able to be self-sufficient.

What's the best way to go about this without affecting my team's ticket health?

I work on the privacy side, so our core projects are often held up by XFN. This leads to me having to find something to do in the meantime, which often means smaller, ad-hoc efforts. However, I've been told that working on larger projects across a lengthier time horizon is better for promotion. What can I do during these blocked times that also shows good execution signal for promotion?

What's the right way to balance interviewing for FAANG roles when you have a full-time job? I've heard of people carving out their morning for an interview or interview prep, so dedicating 2-3 hours. Is this reasonable? What's a minimum amount of time I should spend on interview prep or interview every day?

This question assumes I don't have trouble getting interviews and have a few lined up. The prep I have in mind is the classic DSA/Leetcode, systems design, behavioural, mock interviews, etc.

One thing I'd love to ask about is effective pressure management. Coming from small cos to a big company like Meta; despite startups having a reputation for chaos, I personally find there's a larger number of failure modes at big companies - a review taking too long, lack of good logging, misalignment, which can lead to either a project being derailed or just flat out failing. I've personally gotten better myself at pressure management (trial by fire); but would love to have thoughts from folks on how they work on this skill!

I've heard people say that engineers should learn to cook and not just UberEats and Doordash food all the time. Sounds like a good idea from a health, cost, and relationship-building point of view!

That begs the question of what to cook. Am interested in any ideas! Like all engineers, I don't want to be spending too much time per day doing meal prep, but I'm sure once you do a few recipes a few times you can make them much faster.

Thanks!

And not only equates story points to hours but is constantly looking at your story points and tries to lower them in an effort to push more work to you. I feel like I'm an assembly line worker instead of a software engineer that solves problems. Have any of you experienced anything similar?

I've read enough answers on this platform to know that Alex and Rahul are huge fans of learning Android, both because it's a well-established area of tech (bigger than web) and because you can see how well your apps do. They always mention learning Android, but from my limited understanding, React Native gets you iOS and web as well, and is similar to regular web-dev (could totally be off here).

Isn't it more bang-for-your-buck to learn React Native and perhaps a better use of time?