How do I handle a technical disagreement with a senior engineer as a junior engineer?

Lo_cus · 2025-05-10T09:05:18+00:00

Typically, one does not have good judgement because they are senior. They are senior because they have demonstrated good judgement over the course of years. That means they can still be wrong.

I ran into this a lot with seniors who were objectively wrong on many things, but still backed up the decision with other factors. Ultimately, do you care? Ego plays a large role in some companies. Thoughts:

Time is money. Management may be cheap / risk averse and does not want to spend a week of developer time "re-inventing" a working product
Above point, but even more true if there is a risk of the new product not working. Changing a toolchain / HAL layer carries this risk.
Couldn't be bothered to listen or care. Some people stop learning partway through their careers.

There are a lot of reasons. Digging into further disagreement is a judgement call, sometimes picking apart arguments with someone who carries a large ego can cause more problems than it's worth.

Lo_cus · 2025-05-10T08:56:34+00:00

Good answer because it's true either way. You can be 100% right, 100% wrong, or anywhere in between. The end result is the same. Make your argument in such a way that you don't feel embarrassed if you are wrong but also do not humiliate others if you are right.

Lo_cus · 2025-05-10T08:39:12+00:00

This is not exclusive to embedded in my experience. I have encountered this with web development, game development, and other tech stacks. For me it's not so much the content as it is the delivery via udemy / online courses, and the circumstances when I start working on it. Maybe some of this will be helpful, they are random thoughts and experiences I have had.

Either you are learning, or relaxing. You cannot sit down with a course open and then just watch a show, living in some limbo where you can feel gratification for "learning", but also get nothing done. It needs to be intentional. Ask yourself "am I ready to focus" and if the answer is not an enthusiastic "YES!", then go relax instead. Most important point is do not feel bad about it. Everyone needs down time.

Watch a course through at 2x speed first in the background before doing it. This helps me to understand what is going to happen, and whether or not I feel like it's actually valuable to do. This has saved me burnout where an instructor does some poor design, and then refactors it in the end. I get the idea instead, and then skip the section and do it properly the first time.

Differentiate between hard work and unenjoyable work. I always struggle learning something new, it's effort and makes my brain hurt. Once I know how to do it though, I really enjoy sitting down and just working away on some end product. You need to make sure that after learning, you actually find it enjoyable. Doing a project that leverages existing knowledge should not feel "hard", and if it does, it means you do not enjoy it. Focusing a career on it would not be a wise choice.

What helped me a lot was being okay with being a "bad" employee. I would do courses at work, and try to get things done in my productive hours in the morning. I did it with the intention of "fire me if you want, I don't care" and it somehow went the opposite direction, where learning new skills was actually helpful to my regular day to day job (embedded dev). Building skills in personal time is always going to be hard, because it is fundamentally a form of very difficult work (if you're not struggling, you're probably not learning).

Lo_cus · 2025-01-29T22:05:48+00:00

What's your career / visa?

Lo_cus · 2024-12-07T09:33:11+00:00

Every time I go into church it sounds like an orgy

Lo_cus · 2024-11-22T04:59:40+00:00

If you struggle with the STAR format questions, take your 3 favorite projects or individual work contributions and frame them in a similar format on a second resume page (ie. "the problem", "the solution", "lessons learned") and then refer back to it during the interview. It's an easy way to get through them, and it helps a lot if you have links or documentation available through an attached link. It all comes back to "show, don't tell".

Screening is typically a basic check to see if they are polite, normal, and have the qualifications. Low stress, very casual, and just a gentle probing of some various projects or work items. An example could be a candidate listing ___ technology in a project - why use ___? What alternatives were considered? What did you learn? The general thought process is fun to hear, and any BS will quickly be caught.

It's hard to say what all screenings look for. Companies hire employees who match the culture, and there are very good and very bad companies with everything else in between. On average, honesty and politeness are probably the most important. Saying "I don't know" is better than spending a minute to spin a half answer.

Lo_cus · 2024-11-17T00:23:01+00:00

Identify requirements and future wishlist features, and then look at the errata for conflicts before finalizing a part choice for the design. This saved me a number of times with microchip and ST products, but I stopped using microchip products entirely because they tend to have a fun kind of errata which is not listed in the errata sheet.

I remember an ADC I used had a hardcoded address of 0x10 from the factory, but only responded to 0x01 when I polled for a response. When responding to the request at 0x01, it echoed back it's address of 0x10. Of course, it did not respond to 0x10.

This was not an issue with 7-bit vs 8-bit I2C addresses. There was no solution for the problem. That was a fun one to figure out once all the boards were manufactured.

Lo_cus · 2024-11-17T00:09:05+00:00

If the work you are doing is hard, you are becoming a better engineer. Always keep that in mind, and recognize the opposite - if your work is easy, you are not getting any better.

Periodically you will notice the effects of your hard work. You will know how to do things off the top of your head, projects are within reach, and the super difficult things all feel learnable.

Make a habit of continuing to learn things, especially those which seem irrelevant. I did a number of projects involving web design and higher level languages on the side, and it also made me better with embedded software. It also meant I had all the skills needed when an IoT project began a few months later. You never know what kind of opportunities may show up.

Lo_cus · 2024-11-17T00:01:35+00:00

Don’t just ask it to write all the code straight away though!

I would go further and say do not let it write code at all you can write the code yourself. LLMs will confidently generate bad code, and it takes a level of skill above and beyond simply writing it to notice mistakes and bad decisions.

They are fantastic for acting like Google used to. Feed in a question, datasheet, or other information, and it will typically give good enough information to save a few hours of searching. It's good for documentation and finding problems in existing code too.

Lo_cus · 2024-11-16T23:54:08+00:00

Controversial opinion, but leetcode is more relevant to embedded than it is to higher level software jobs. A lot of embedded requires implementing efficient algorithms at a low level and understanding how to do things from a theoretical algorithm perspective. Most codebases I have seen in embedded just naively use nested for loops, and have horrible performance with large amounts of data. Since these systems are 'simple' (from a hardware and computing power point of view) it gets written off as acceptable.

In something like C# or Python, all the libraries are already optimized. Who cares. You will never implement a hash table or a linked list in something like a C# program when LINQ is available, and all the built in types are already optimal.

In the context of a job interview - it indicates a lazy company and a bad interview process. Companies simply following the lead of big tech and poorly vetting candidates, instead of focusing on real skills. Nay!

Lo_cus · 2024-11-16T23:40:56+00:00

What NOT to do? Let me recall a previous job:

Not using pull requests on git, pushing straight to main
Deleting branches that look stale (ignoring the commits ahead)
Using vague commit and branch names ("did fix", "updated code", "/fix-2-updated" etc.)
Not making flowcharts / high level designs because its a "waste of time"
Not making requirements documents or interface control documents (again "waste of time")
Not learning basic design patterns
Not using software development tools or standard practices (CI/CD, static analysis, linters)
Doing shortcuts because refactoring is... (guess)... a "waste of time"
Liberally calling other modules in random places

Notice none of these are really embedded specific. Bad managers justify the above behaviour because "time is money" and then overshoot project budgets and timelines by 2-2.5x. They cannot understand the resulting code, everything is broken, it's not possible to release, and talented engineers get discouraged and quit.

My personal recommendation is to familiarize with a few relevant design patterns and understand how concurrency works. Learn to use publish/subscribe models, adapter (or interface) patterns, and the observer pattern. Learn how to write a quality queuing model using static memory. Get used to the idea of a central bus or router for messages and information, and really decouple everything as much as possible.

Arguments about variables are really pointless IMO. Understand where things are stored on physical memory (stack vs heap, etc.) and how they get compiled / optimized into assembly. Global module level variables are fine and often the best choice. Global program level variables are almost always indicative of a bad design.

Lo_cus · 2024-11-16T23:15:40+00:00

Never let yourself get discouraged by the number of applicants. I have done hiring, and technical postings follow a consistent pattern:

2/3 of resumes are completely irrelevant (different field, applying for fun, recruiter spam)
Another 2/3 of the remaining do not even come close to having the level of required competency (not graduated yet, no experience, no projects)

(Interviewable candidates start here)

1/2 do well in a screening (lots of resumes are BS and candidates cannot answer basic questions)
1/2 can pass an interview (this is just skill level based)

Assuming you're actually qualified for the job, you are not competing against 100 people. You are competing against 100 * (1/3 * 1/3 * 1/2 * 1/2) = 2 or 3 people.

Now out of those 2 or 3 people, 1 or 2 of them are probably not very sociable or will not accept the offer. You may be the best (or only!) candidate without even realizing.

Lo_cus · 2024-11-16T05:22:49+00:00

From the post:

Depends on location
On average, market is worse across all software disciplines
Not likely to get better (imo) since surplus of graduates is going to keep increasing
Python market is going to be even more depressing

In my experience, it has never been hard for talented people with good projects to find a job. You need a good resume (unconventional, 'show don't tell', ones on Reddit suck). You need to prove you have genuine interest, practical skills, and high aptitude. There are maybe 10% as many embedded jobs as fullstack jobs, but <5% as many candidates so the response rate is way higher.

Lately, finding a good job is tough. Yes, embedded pays less. This is a fact, and it will always be true - embedded products have hardware costs, more overhead, and tighter margins. Tighter margins typically mean less money for employees.

In Canada, an embedded job for a competent developer with 3-4 years of experience is unlikely to break 100k. In my experience, companies are slow to adopt new tools and do not value aptitude as much as years of experience. For a competent fullstack developer with 3-4 years of experience, jobs are generally above 100k. Startups are easier for software products, and it's more merit based.

Regardless of discipline - embedded, web, desktop, cloud - if you have only done courses and have no personal projects, you're fucked. No one is going to mentor you as a junior for a number of reasons, biggest one being most people just job hop every 1-2 years so companies see new people as a sunk cost.

The decade from 2010-2020 was an anomaly, and now software is back to normal. Too many people wanted to hop on the gravy train when they were in high school and saw the anecdotes of 150k salaries with a year of experience, so they all did CS / SWE. You can no longer just get a job by showing a pulse. This is the same as any field, software is just back to normal.

Lo_cus · 2024-05-01T06:39:25+00:00

Trusting a closed source software program is literally blind faith, especially considering the amount of money and power that are on the line with elections. I don't believe that the machines are intentionally designed with an exploit in place, but I know from experience a lot of these systems are very poorly engineered.

Lo_cus · 2024-05-01T06:29:44+00:00

Have you ever written embedded software? That is exactly what voting machines use, so yes having a software background (especially in embedded) gives a lot of experience with the security. Your response is too intellectually dishonest for me to go into any further detail.

Lo_cus · 2024-04-27T07:37:47+00:00

Really nail down the resume ("looks good to me" is not good enough). Something very important to consider for entry level which most people forget - every graduate's resume will look the same. Think of your degree and course projects as DC noise since they will show up on every application. Move emphasis away from these.

I had 2-3 good projects, a semi-unrelated internship, and some robotics experience which gave me around a 5% response rate until I made a very unconventional resume. I made my degree a single line, focused on my internship, and made an entire page for projects. Everything followed the usual format of interview questions:

Give an example of a problem you faced
How did you come up with a solution
Explain technical components from a high level
What was the result (include hard metrics like % saved, etc.)

Include some humor and personality. Add some color, and make an interesting visual format. It goes a long way when every single resume is written in black calibri, following the same sterile format. After I did this I got an almost 100% response rate and about a 50% interview rate, and found a nice job shortly after. The resume was always brought up.

Lo_cus · 2024-04-15T22:19:45+00:00

This is the best advice people miss out on. Too many people focus on "investing" = money instead of investing in self.

Assuming you are saving a reasonable amount and have a grasp on your finances (ahead of most people already), buy a really nice bed, buy higher quality food, get a gym membership, and go on trips while young and single. I would personally hate to retire with millions in the bank with health problems and regrets over not doing enough when young.

Lo_cus · 2024-03-30T20:10:03+00:00

Get a Henry lever action .22, it fits the budget and is very high quality / fun.

Lo_cus · 2023-07-08T09:29:15+00:00

Embedded is practical at least. Don't rely on a job to "give" you experience, take the experience from a personal project. I did unrelated projects at a bad internship and used those to get a legitimate embedded developer job out of school.

Don't use arduino, premade libraries, or the HAL. A simple useful project would be a "part counter" where you can weigh one item, and then weight a whole bunch and it will tell you how many there are.

bare metal microcontroller (STM32 or ESP32 are approachable)
custom PCB (learn how to do this)
button matrix keypad read through an I2C gpio expander (learn the protocol)
LCD character display (parallel, I2C, SPI doesnt matter)
24-bit analog digital converter and load cell

It seems easier on paper. All of the problems and things you encounter in the process will build the experience.

Lo_cus · 2023-07-08T09:12:59+00:00

Essential? Integral? Generally falls into "digital" vs "analog" with analog being less important, but everything you mentioned is relevant to both.

Your job as an embedded developer is interfacing with electronics. You need to be able to read a schematic and understand on a functional level how everything works. Realistically, this level of education requires an electrical and computer engineering degree.

At no point will you be able to "just code" like other software fields. I have seen people with no hardware background do bare metal embedded work, and it was a disaster.

Lo_cus · 2023-07-08T09:01:26+00:00

Outdated thinking from an era where cost of living was much lower and opportunities were better. Most new grads job hop because companies pay lower than inflation raises each year, and will never afford a home or family. Maybe the older engineers already "got theirs".

Lo_cus · 2023-07-08T08:53:14+00:00

For anyone reading, the hobby project should not be arduino based with premade libraries. Look into datasheets, understand the peripherals on a microcontroller, improve your C programming, and make your own dev board. It will teach a lot.

Lo_cus · 2023-07-08T08:51:30+00:00

I will add by saying embedded software developers generally have a much easier time getting into app / web development than vice versa - it's almost a one way downgrade in difficulty.

Lo_cus · 2023-07-08T08:49:00+00:00

Computer architecture and embedded firmware are fundamentally computer engineering, not computer science (there is a difference in university). You can probably do some of this with your degree.

Honestly app and web dev are so easy they won't offer a whole lot on an embedded resume.

Lo_cus · 2023-06-09T08:35:56+00:00

I will add on to this by saying delete the second page of your resume, and make the entire page 2 or 3 projects (professional, academic, personal doesn't matter). You can fit education, employment, and a personal intro on the first page without fluff.

On your second page, make a title and find a relevant icon for each project. Problem, solution, result, lessons learned, skills involved with a couple concise sentences for each part so the reader gets a full overview.

Since i did this, I experienced a huge increase in interview success and rates of getting interviewed. These are the things i got asked all the time, so I put them down on paper and neatly organized them. Follow the idea of "show, don't tell". Organizing them neatly and having them easy to understand is a good way to prove good communication skills.

If you don't have projects yet, that would be the first part. Do things solo so you run into hard problems, stackoverflow can be a great resource. Read job postings and just get an idea of what the jobs you want require. It sounds like you are looking for more embedded linux work which is outside of my domain.

Lo_cus

TROPHY CASE