_edited.png)
What an Application Engineer at Broadcom Wishes They Had Known Before Entering the Engineering Industry
Rasheek, a Staff R&D Application Engineer at Broadcom, learned that this role is far from a "one-man show," requiring the ability to build upon existing work, even if flawed, and navigate the challenges of securing buy-in from multiple teams resistant to change, especially within a large company facing budget constraints and the risk of not improving upon established products. The interview revealed the significant hurdle of transitioning from independent academic work to collaborative, legacy-dependent professional engineering.
Teamwork, Problem-Solving, Overcoming Challenges, Industry Realities, Workplace Challenges
Advizer Information
Name
Job Title
Company
Undergrad
Grad Programs
Majors
Industries
Job Functions
Traits
Rasheek Noor
Staff R&D Application Engineer
Broadcom
UC Davis
UCLA Anderson - MBA
Engineering - Electrical
Technology
Product / Service / Software Development and Management
None Applicable, Immigrant
Video Highlights
1. Collaboration is key: The role requires significant collaboration with other teams, handling existing work (both good and bad), and gaining buy-in for changes.
2. Dealing with legacy systems: Be prepared to work with existing systems and code, which may have flaws or inefficiencies. Completely overhauling systems may not be feasible due to time and budget constraints.
3. Impact of changes: Implementing changes can be challenging, especially in established products used by many. Demonstrating the value and necessity of changes to multiple teams and stakeholders is crucial.
Transcript
What have you learned about this role that you wish someone would have told you before you started?
The first thing I learned is that it's not a one-man show. In undergrad, I was very independent and tended to work on projects by myself. Even for group projects, I would usually be calling the shots and making most of the decisions, whether it was for a senior design project or a homework assignment.
Someone may have been in your job before and done great work, but also done bad work, and you have to deal with what's on your plate. It's hard to learn and develop the skills to take another person's work and move forward with it. In college, assignments typically don't allow for this.
This is one of the biggest hurdles you have to go through. You need to understand that the person in your job before, or who left the company, may have left holes in their product, hardware, or software. With time constraints, you don't have the luxury of restarting from scratch.
You're essentially building on what's already there, whether it's a good or bad foundation. Changing that foundation requires a lot of buy-in from multiple teams. Those teams might ask why they should change something that's been working for years, operating under the "if it ain't broke, don't fix it" mentality.
Many people have a hard time adjusting to this at first. It varies across companies, from larger ones like Broadcom to even "bang companies." Trying to change a product without the budget to redo it from scratch is very difficult.
Many executives today won't allocate the budget for such a thing. There's also no guarantee that anything new you build will be better than what already exists, especially if the product requires a lot of end-user adoption. It can be very hard to change a specific product or development approach if it's already ingrained in a team and the company as a whole.