What an internship is actually for
I went into my embedded internship thinking it was about adding a line to my resume. I came out realizing it was the first time anyone had ever pushed back on my work.
College grades you on whether the LED blinks. An internship grades you on whether the LED blinks reliably, every time, on someone else's board, six months from now. That is a different problem, and nobody warns you about it.
The shift is uncomfortable in the best way. You stop being graded on intent and start being graded on outcome. The first time a senior calmly told me 'this works for you on your desk, that is not the same as working,' a piece of how I think about engineering rearranged itself permanently.
Debugging stops being guesswork
Before the internship, my debugging strategy was 'add more print statements until something changes.' At Emertxe, that habit died in week one.
The new loop was simple but strict: form a hypothesis, isolate one variable, pick the right instrument — logic analyzer, multimeter, scope, UART logs — verify, write it down. Reproducing and documenting 10+ defects forced the discipline. After a while, the loop runs in your head automatically. That single shift is probably the most career-defining thing I picked up.
The subtle benefit is that the loop also tells you when to stop. If three hypotheses have failed in a row, you are working on the wrong layer of the problem. Step back, re-check assumptions, re-instrument. Most of the long debugging sessions I have had since college ended because of that one habit, not because I got smarter.
Documentation is not bureaucracy
I used to think writing things down was something you did to look professional. Internship convinced me it is something you do so you do not have to solve the same problem twice.
Every bug got a short writeup: what I expected, what I saw, how I narrowed it down, what fixed it. Six months later those notes were more useful than any tutorial I had ever read, because they were specific to the boards I actually used.
The template I still use is four lines. Symptom. Suspected cause. How I verified. Final fix. Anything more is overkill for daily work. Anything less is too easy to skip when you are tired. That little template has saved me hours of re-debugging on more projects than I can count.
Asking better questions
The fastest way to look like a junior is to ask a senior 'it does not work, what do I do?' The fastest way to look ready is to ask 'I expected X, I see Y, I have ruled out A and B, where should I look next?'
That reframing alone changed how seriously people took my questions. It also forced me to do real work before asking — which is the actual point.
As a small bonus, the act of writing the question out usually answers it. I have lost count of how many times I have started typing a Slack message to a senior, gotten halfway through the 'I have already ruled out…' section, and realised I had not actually ruled it out. Half of mentorship is just learning how to be specific.
The boring habits that compound
Pull the latest code before you start. Commit small. Write the README before the code. Label your wires. Save your scope captures with the bug number in the filename.
None of this is glamorous. All of it pays back the moment something breaks at 9 p.m. the night before a demo.
The meta-habit is treating your future self as a coworker you are nice to. Every commit message, every filename, every README is a tiny gift to the version of you that has to revisit the project in six months with no context. That mindset alone has done more for my engineering than any framework I have ever learned.
If you are heading into your first internship
Show up curious, not impressive. Read the existing code before you write any. Ask what 'done' means before you start. Write down everything you learn — you will forget more than you think.
And treat the internship as the first real engineering job, because that is what it is. The next one will feel a lot less mysterious because of it.
One more thing: by the end of the internship, you should be able to name three things your team does well and one thing you would do differently. If you cannot, you spent the months heads-down on tickets and missed half of what an internship is for. The point is not just the work — it is learning to read an engineering culture.