I would echo what Alex said. This differs from team to team. Keep in mind that if your friend is working \~135 hours per week, then their pay is not actually that great when considered on a per-hour basis.

I think what your friend is describing is nowhere near the industry average. Beyond what Alex wrote, I want to say that I find people love looking very busy, because they conflate busyness with importance or impact. They are not the same. For this type of role, working a lot is possible for some people, but most people would likely burn out doing challenging work for many hours and not actually sustain the high level of effort required. There is research on this (see Cal Newport's *Deep Work*, which covers how few people can do more than 4 hours of deep work a day). They are also more likely to make mistakes, which they then have to spend time fixing later. So while it's likely your friend is working significantly more than average, I would take everything anyone says with a grain of salt, especially if they are saying they barely sleep or eat and do nothing but work.

My recommendation would be to network with other engineers, learn about different companies' cultures, and get a sense of the day-to-day. Few things people are working are urgent and critical to the world to get done ASAP. It's normal to have the occasional crunch where you need to focus and get something out quickly. It's not normal for it to be the norm. If that's the case, the team needs to hire more people. So I wouldn't worry about this, and I'd get exposure to the perspectives of other engineers. I'd also talk to my friend about whether they might want to look at other teams/roles, but that's just me.

Senior Software Engineer [IC3] at Nvidia

David Yastremsky

Everyone's mind works differently. If you already have experience coding in other languages and are skilled in reading documentation, starting with building could be the way to go. Personally, I usually skim the basics of a language (e.g. syntax), check how it compiles/builds/runs, then get started coding in it.

Where tutorials really thrive is taking people who have no/limited coding experience and getting them building something. It's also helpful for having a structured way for learning specific things. For example, there could be a tutorial that uses C++ concurrency, and it could help getting you thinking correctly about concurrency. You could pick up concepts you would not have otherwise and gain abilities to build projects similar to the tutorial. If you are not looking for that or prefer to jump straight in, do! You'll quickly find out what you don't know and be ability to iterate quickly by looking up the concepts relevant to you building your CLI tool.

If it was me, I would look to create opportunities. I would also change the objective function here. It sounds like everyone on the team sees an opportunity created for them and fights for it. However, that's all about them. If you are instead trying to improve the product and project, find what will help the product the most. That will naturally lead you to the most impact.

Taro has a lot of videos with examples of projects that have the scope to help people make mid-level, senior, and staff project. Those often involve finding pain points (e.g. in the development process, for customers, etc.) and addressing them. Do that start to end. Find a high-impact opportunity, gather objective proof it needs to be addressed, then create a prototype solution. Present it and gain consensus. It's obviously something you are leading then. Once you convince others it is important, they can help you. And you can do it well, leading an improvement start-to-end. Including gaining adoption, documenting it, selling it, and measuring the impact at the end.

Occasionally, you are lucky and given scope within a project (e.g. retiring engineers or engineers who are promoted and give it to you). That's what many people are looking for. However, the thing most within your control is creating scope *that delivers value*. That's also most valuable for the product and makes the strongest case for a promotion, in my opinion.

This really depends on the recruiter and your relationship with them. As a general rule, I would not provide information to them about other interviews, short of letting them know you are recruiting independently to be transparent with them. This assumes good faith and a solid recruiter.

I think telling them your desired compensation range would be a more effective use of both of your times. They are there to find you a role. If you are looking for, say, $120-150k, and their matching roles only go up to $100k, then they know sending those to you is a waste of time for both of you. Typically, these agreements pay them on commission, so you getting a higher compensation is beneficial to them. Perhaps that's changed recently. Even so, I don't expect they gain much by getting you to take lower pay unless it gets you to take a job you otherwise would not have. In my experience, being upfront with recruiters about what my expectations are and how important each is have been helpful.

Edit: To alleviate your concerns, your recruiter is incredibly unlikely to contact your current companies and harm your chances. That would not make sense. I only say above to not tell them specifics because there is no reason they need to know that (except in the case that they want you to look at the same role through them, in which case you can simply decline to be referred for that one).

Ryan gave a great detailed answer. I'd like to add a small thing: you need a feedback mechanism. You'll never know why you failed unless the company tells you, which is rare, especially for them to provide the objective reason. And a lot of it is not dependent on you, such as the performance of other candidates interviewed for the role. To improve on the part that is within your control, you need to get feedback.

Try to get some mock interviews. Get them with different people who have experience interviewing for the roles you are applying for (e.g. software engineer roles). There are services to do this, but I'd advise getting friends, colleagues, or fellow Tarodactyls. You want to get different, quality perspectives, so you can filter out the noise. Getting that feedback is invaluable.

Again, there are a million reasons that someone may not get a role. A competitive market. Funding drying up for a role. A manager looking for a specific skill. A start-up CTO finding a candidate who is incredibly passionate about their company. A lot of that is not in your control. However, if you want to become the best candidate you can be, you need to get and integrate interview feedback. Mock interviews are a great place to do that.

Note: After typing this up, I realize Ryan mentioned recording yourself and creating a feedback mechanism that way. That is a great approach. I do think mock interviews get even closer to a real interview situation and get you feedback from others, so they are a valuable addition, but that's a pretty ingenious approach to bettering yourself that I'd definitely give a try.

This depends what roles you are applying for. Are you looking at Software Engineer, Product Managers, or other roles? What kinds of companies are you applying to? You can generally find mock questions on Glassdoor for larger companies. For software roles, Leetcode (data structures & algorithms) tends to be the gold standard. When looking for the answer to this question for you, you'll want to look online or ask here based on what you are applying for.

As far as the behavioral questions, there are some themes, but it will vary by interviewer. Some companies have specific requirements, like Amazon focusing on their Leadership Principles, which you want your stories to relate to. Preparing detailed, clear stories for different themes is important. You can look up formats like the STAR method.

Once you have interviews lined up for specific roles at specific companies, you can make your preparation more specific. Until then, think about the roles you want to apply to and cater your interview preparation to generally getting ready for those roles.

Have you tried looking up questions for that company on Glassdoor or Google? Every team and interviewer is different, especially when you move into the start-up world. That said, you might be able to find questions for the company on Glassdoor. 

Overall, your best bet is to talk to the recruiter to clarify expectations around the interview process. They should want to help you prepare and give you clear expectations, especially if this is a place you would want to work. Most recruiters would also take this as a positive sign that you are interested and taking their interview process seriously.

Beyond that, general interview preparation (e.g. understanding algorithms and data structures) is always important. Also, especially for a start-up, look at the role you applied to and be ready for questions related to the requirements and responsibilities of the role.

What I'm hearing in your question is the assumption that you need to be able to do all the things. This is a common issue in today's world, where time is so carefully measured and opportunities for using your time are endless. Even those who manage to do many things, have many experiences, contain many great things in your life, etc. then want to use their time to have even more things, experiences, and things. There is always a tradeoff.

You need to prioritize. In that process, question your assumptions. Are there things in your life where you use time that do not add sufficient value? For example, social media can be one of those things for people. You are not a robot, so you cannot remove all of it, but that is a reasonable question. Based on your question, I assume that you have probably looked at many of those things and have little free time.

Then, it comes to priorities. What are your values? How do you live in alignment to them? What will you value or regret on your death bed? This is a great chance to re-evaluate how you want to be living your life. Jumping to a much less challenging job now might make sense if you are very burnt out and that would help. It sounds like that would make you unhappy, as someone who seems to value ambition and career growth highly.

This question sounds more in the realm of one for a mental health or coach. You can do a lot on the professional side. Figure out your goals, set clear boundaries with your team, and see what it takes to achieve the career success you want and what the costs are for each possible level of success, then decide what is optimal. But a lot is outside the scope of careers. Maybe you want to have a conversation with your partner about what you need. Why is their career more important than yours? What would make sense for both of you in terms of contribution to your kids and the household? I would engage with a professional who can help you think through these questions or, at a minimum, think through them yourself. You cannot give 100% of your resources to being an engineer, 100% to being a parent, 100% to being a partner... and so on. And you will burn yourself out trying.

That is very dependent on your company and team. You should speak with your manager. Since interns are already a net negative financially for most teams, it's rare to have the budget to provide overtime or for it to make sense to do so.

Where it gets tricky is that, legally and ethically, you should bill for any time you are working when you are hourly. However, if the decision is not being dictated by the project needs and your manager, then you are choosing to work longer for your learning. That's more your choice and could be considered outside of work. I wouldn't work longer hours and bill for them without talking to your manager. Doubly so if you are doing it to maximize your learning versus responding to project requirements.

It won't make much of a difference. The point of an internship from the company's perspective is to train and hopefully recruit you, assuming it's a match. The assumption is you'd like to convert your internship to a full-time offer.

With that said, you should treat this like an engineer anywhere else. Create goals for your summer, communicate those goals with your manager, and have open communication about progress and blockers. Those goals should center around things like getting to know people, clarifying career goals, and making an impact. They should not be about securing an offer, which would be a secondary effect of making progress towards your goals. It's company-specific, but by the middle of your internship, conversations around your return will likely start. You definitely don't want to only start them at the end. This will make it clear you want to return and clarify what that process looks like for you.

And remember, this is an opportunity for you beyond getting an offer. You can learn. You can meet people. You can explore your career before starting. Teams love interns for the energy they bring to a project. It can get exhausting for people when interns start talking about returning from day 1, before they even met anyone or got a sense of the team. It makes it seem that much more disingenuous. Bring good energy, learn, meet people, work on some cool things. That's what gets you a return offer, which most companies want to give you anyway. Talking about converting daily will exhaust you and those around you, and you'll get far less from your internship than you would otherwise.

You’re really overthinking this. PIPs suck, but they happen. Many factors could lead to them. It wasn’t a fit at that time, with that company, with that team, with you. It doesn’t say anything about you or your performance. You got PIP’ed once, so I wouldn’t worry that you’re not a fit for that type of company or anything else. I’d focus on getting that next role, then you could lean on the Taro community for optimizing how you navigate it.

Also, don’t reveal that you were PIP’ed. It’s irrelevant. Your previous company won’t reveal it due to fear of lawsuit. They’ll just confirm your employment. Don’t overthink this.

Nvidia

Mid-Level Software Engineer [IC2]

I've found getting patents to be completely orthogonal to software work. The best way to learn how to do them at your company is to work on one. If you have engineers on your team who would be willing to have you help out with the patent, then you should definitely offer to do help as much as you can. In theory, this would be worth it for the experience alone, but it's possible they may decline (depending on how your company incentivizes patents and their personal incentives) since taking your help would almost certainly necessitate putting you on the patent. If it doesn't, then you could offer your help without being named an inventor since you're learning via this experience.

While I agree with Alex that there's little reason for most software engineers to go after patents, if you choose to do so, that's the path I'd take: getting experience and mentorship by someone who has several patents. If you can't find someone willing to accept help with a patent, then learning about the ones your teammates put out and coming up with ideas could also be helpful. You can see what your teammates think of your patent ideas. They may help you refine them, give you a sense of direction, and possible suggest you go forward with an idea eventually (and they'll almost certainly help, so you'll get mentorship here too). Keep in mind that even if your patent is filed by Legal, it'll likely be 12-18 months before any conditional patent is available via public search and years before it's approved. And it'll be the company's patent, though you'll be listed as an inventor.

Definitely consider your motivation before you go through this process though. It's a good amount of work that's unrelated to your work, and you won't advance your career this way (unless you're going somewhere where patents are the norm, e.g. some research scientist roles).