Skip to content
eeprep

How to interview

Expect a long, tiring process, and know everything you put on your resume in full detail. Interviewers keep asking until they find the edge of what you know. Prepare in this order: your projects, then fundamentals, then coding, then behavioral stories. Before you apply, try to get a referral.

The advice here comes from career center guides, hiring research, posts from engineers, and my own interviews.

What the process looks like now

Section titled “What the process looks like now”

The process can run long: several rounds, a take-home test, and an in-person day of back-to-back sessions. Michigan Engineering's career center says some employers hire after one interview and others run multiple rounds (opens in a new tab). MIT's career office says timelines vary by company and industry (opens in a new tab). Some candidates hear back within days, and others wait weeks or months. Plan for the long version.

A typical process

Timeline of a typical hiring process: an application, a recruiter screen, a technical screen, a take-home test at some employers, a call with the hiring manager about your projects, an interview day of back-to-back sessions, follow-up calls at some employers, a recruiter call with the decision, then an offer.

A typical hiring process. Employers skip, merge, or add steps.

Your process may skip some of these steps or add others. Expect at least one call with the hiring manager about your projects.

Each round goes deeper than the resume. A recruiter on X says hiring managers now go 3 to 5 layers deep (opens in a new tab) on whatever you say: "How did you do that. Why that way. What broke. What would you do differently." The same post says candidates who padded their resumes with AI got caught in later rounds. One embedded new graduate found that interviewers rarely asked the same project questions twice (opens in a new tab). Another early-career engineer said they kept getting "hammered with harder questions until they can stump me" (opens in a new tab). Expect to reach your limit.

Entry-level roles run long too. One EE was surprised that a trainee position came with a 70-minute technical interview (opens in a new tab). The engineer roles they applied to next ran the same way.

Many employers score you against a fixed set of questions. The US Office of Personnel Management defines a structured interview (opens in a new tab) as one where every candidate gets the same questions in the same order. Every answer is scored on the same scale. A 2022 review of hiring research ranked structured interviews first among the selection methods it compared (opens in a new tab). For you, that means the same topics come up for every candidate, so you can prepare for them.

How to prepare

Section titled “How to prepare”

Start with your own projects, because that is where the follow-ups go deepest. One embedded intern wrote that the resume is just the step in the door (opens in a new tab). The rest happens when you talk about your work.

Your projects, line by line

Section titled “Your projects, line by line”

Every line on your resume is fair game, and the questions go several layers down, sometimes for a full session on one project.

Questions go layers deep

One resume bullet about a buck converter, followed by four deeper questions: how did you do that, why that way, what broke, and what would you do differently.

Interviewers ask about one line, then go 3 to 5 layers deep on each answer. Prepare every line on your resume this far. Source: a recruiter's post on X (opens in a new tab).

For each project, write out answers to these before the interview:

  • What does it do, in two sentences?
  • What part did you own?
  • Why did you pick each major part, tool, or method?
  • What broke, and how did you find it?
  • What did you measure, and with what instrument?
  • What would you change on the next revision?

The last questions come from Michigan Engineering's guide to interview talks (opens in a new tab). It lists the follow-ups interviewers ask most, and they also ask what alternatives you considered.

Take Alex's CubeSat buck converter. Expect "Why a buck converter and not an LDO?" Hardware FYI lists that exact trade-off among common analog questions (opens in a new tab). Alex also needs to say why [X] W, how the [X]% efficiency was measured, and what loads were tested. If Alex cannot explain a number, it comes off the resume.

Fundamentals from the ground up

Section titled “Fundamentals from the ground up”

In my experience, a system design question can be as broad as how to build a computer from the ground up. The answer can go down to interrupts, how the CPU executes code, and pipelining. MIT's free Computation Structures course (opens in a new tab) covers that path, from CMOS gates to a pipelined processor, devices, and interrupts.

Review the topics your resume and the posting touch first:

Hardware interviews mix these. One commenter on a Microsoft hardware internship thread reported 2 rounds of about 55 minutes (opens in a new tab), covering C, embedded projects, and some behavioral questions.

A note on embedded interviews

Section titled “A note on embedded interviews”

Embedded questions cross the line between hardware and software. An EE degree can land on a hardware or a software team, so be ready to talk about both sides of each project.

Pick one project and trace it from the pin to the code. Say Alex reads a sensor over I2C. Alex needs to explain what the bus does, what the interrupt handler does, where each variable lives, and why a flag set in the handler is volatile. Nigel Jones of Barr Group names that case (opens in a new tab) among the three where the keyword is needed. If you cannot walk the whole path, that gap is what to study next.

Then name which of I2C, SPI, and UART (opens in a new tab) you have used, and what went wrong with it. A real bug is a better answer than a definition.

Coding problems out loud

Section titled “Coding problems out loud”

Expect a LeetCode-style problem on a whiteboard in some hardware loops. Hardware FYI says many hardware roles at big tech companies expect you to code (opens in a new tab), with problems such as merging two sorted linked lists.

Practice the format as well as the problems. Illinois Engineering Career Services says many students struggle with whiteboard coding (opens in a new tab) if they have not practiced that specific format. Solve problems on paper or a whiteboard with no editor, and talk the whole time.

Practice with someone watching. In a 2020 study by NC State and Microsoft researchers, having an interviewer watch cut performance by more than half (opens in a new tab). The study had 48 computer science students solve the same kind of problem in private or in front of an interviewer. You cannot remove the audience on the day, so get used to one beforehand.

At the board, follow Michigan Engineering's technical interview advice (opens in a new tab). Think out loud, watch for the clues the interviewer gives you, and ask when you are stuck. Georgia Tech's career center says to clarify before solving (opens in a new tab), and that many technical interviews give credit for a sound approach. Restate the problem and ask for what you need before you start.

Behavioral stories

Section titled “Behavioral stories”

Behavioral questions ask about something you did. "Tell me about a time you failed" is the classic. Answer with STAR: situation, task, action, result. MIT's career office suggests spending about 60 percent of the answer on the action (opens in a new tab), with "I" statements about your own part.

Where a STAR answer spends its time

A bar split into Situation (20 percent), Task (10 percent), Action (60 percent) and Result (10 percent).

Spend most of a behavioral answer on what you did, and use "I", not "we". Source: MIT's career office guide to the STAR method (opens in a new tab).

Michigan Engineering tells students to prepare 5 to 10 success stories (opens in a new tab). The same page says employers often find student answers not specific enough. An EE story needs a part number, a measurement, or a date. Here is Alex's, with the brackets left to fill in:

Situation: [N] weeks before integration, the CubeSat power board ran hot at [X] A.

Task: I owned the power board.

Action: I measured the switch node on the scope and found [cause]. I changed [part or layout] and retested on an electronic load.

Result: Efficiency went from [X]% to [Y]%, and the board passed integration on [date].

Say your stories out loud before the day. The Colorado School of Mines career center tells students to write their answers down, then practice saying them out loud (opens in a new tab). Expect fit questions too, such as expected daily hours and work-life balance. In my interviews, a last call with a senior leader worked as a final test of confidence.

The project talk

Section titled “The project talk”

Some loops I have been in asked me to present my own work, and the engineers listening interrupted often to push for detail.

Michigan Engineering describes a 30 to 60 minute session, with 20 to 40 minutes for the talk and the rest for questions (opens in a new tab), plus probing questions to test whether you understand the details. Its advice is written for PhD candidates, and it fits any talk. Cover the problem, your approach, the trade-offs, and the outcome. Rehearse in front of friends, and ask them to interrupt you.

Take-home tests

Section titled “Take-home tests”

From what I have seen, a take-home can ban AI tools. Expect an open-ended problem with no perfect answer, judged on what you choose to optimize.

Follow the rules exactly, including the AI rule. Decide early what you will optimize, such as speed, memory, or readability, and write that choice down with your reasons. Georgia Tech's career center says your reasoning matters as much as the final answer (opens in a new tab), so explain the trade-offs you made.

Mock interviews

Section titled “Mock interviews”

Illinois Engineering Career Services calls a mock interview the best way to prepare (opens in a new tab). Michigan Engineering offers them (opens in a new tab), and the Colorado School of Mines runs peer-to-peer mock interview sessions (opens in a new tab). Book one at your school's career center before your first real loop.

Treat it as a conversation

Section titled “Treat it as a conversation”

An interview is a conversation, and both sides want it to work out. The company opened the role because it wants to hire someone, and you want the job. A long process is still a company trying to fill an open role. Go in with confidence and don't put the interview on a pedestal.

The questions are less of a trap than they feel. Michigan Engineering says recruiters and hiring managers want to know three things (opens in a new tab). Those are whether you can do the job, whether you will, and whether your values and work style match theirs. Colorado School of Mines calls an interview a chance to share your skills and discuss how you may be a good fit (opens in a new tab). Michigan also calls the job search a two-way street, so you're sizing up the team too.

Prepare and practice out loud, as the sections above describe, and then stop, because more worry past that point won't make you better. Stay calm and collected, listen to each question, and think out loud in technical interviews, as Michigan advises (opens in a new tab).

On the day

Section titled “On the day”

Every part of the visit counts. On visits I have made, a tour or a lunch was part of the evaluation, and an engineer asked me how I thought a piece of equipment worked. Give your best guess and your reasoning, with a positive attitude and a willingness to learn. Illinois Engineering Career Services says to be at your best during the entire experience (opens in a new tab), because anyone could have a say in hiring.

The sessions I sat through ran back to back, mostly at a whiteboard, so expect a lot of standing. Explain your thinking out loud in every one. The same skill matters on the job, where you explain your reasoning and defend your work.

If you do not know, say so. Be confident, not arrogant, and never bluff. Interviewers can tell. MIT's career office warns that bending the truth can come across as disingenuous (opens in a new tab). It may also contradict your resume or what a referral said about you. Say what you do know, then reason toward the rest.

Bring questions for each interviewer. An in-person day with several sessions needs more than one good question. MIT's career office has a list of sample questions (opens in a new tab). These three work for an EE role:

  • What kinds of assignments might I expect the first six months on the job?
  • What skills do you see as most important to be successful in this position?
  • Is there anything we discussed today that would give you concern about my candidacy?

Georgia Tech's career center says to skip questions the company website already answers (opens in a new tab).

After each round

Section titled “After each round”

I have had a recruiter call after every round to set up the next step and ask whether I expected to move on. Have an answer ready: say it with confidence, and name what went well and what went poorly.

Write notes the same day. Michigan Engineering suggests noting the questions you struggled with (opens in a new tab), so you can study them before the next round. The embedded new graduate above wrote notes after every interview (opens in a new tab).

Send a thank-you email within 24 hours. Illinois Engineering Career Services gives that window (opens in a new tab). Michigan Engineering gives the same window and says to restate your interest and add skills you did not get to mention (opens in a new tab). Keep it short.

Further reading

Section titled “Further reading”

Start with these guides: MIT's STAR worksheet (opens in a new tab), Michigan Engineering's interview guide (opens in a new tab), Georgia Tech's undergraduate interviewing guide (opens in a new tab), Illinois Engineering Career Services interview basics (opens in a new tab), and Nigel Jones on the volatile keyword (opens in a new tab). For practice, use Georgia Tech's Interview Ready guide (opens in a new tab), MIT's sample interview questions (opens in a new tab), and a community list of hardware engineer interview questions on GitHub (opens in a new tab).

Prep sheet

Section titled “Prep sheet”

Fill in the brackets and finish this sheet before the first phone screen.

Interview prep sheet

Company and recruiter

  • Company and role: [Company], [Job title], job ID [12345]
  • How I applied: referral from [Name] / applied cold on [date], day [N] of the posting
  • Format from the recruiter: [N] rounds, take-home [yes/no], in-person day [N] hours

Projects (one block per project on the resume)

  • Project: [Name]
  • What it does, in two sentences:
  • My part:
  • Each major part or tool, and why I picked it:
  • What broke, and how I found it:
  • What I measured, and with what instrument:
  • What I would change on the next revision:

Fundamentals (check off after you can explain it at a whiteboard)

  • What happens from an interrupt to the return
  • volatile: registers, ISR flags, shared globals
  • Stack, heap, and where each variable lives
  • How a CPU fetches and executes, and what pipelining does
  • I2C, SPI, UART
  • Op-amp gain, RC filters, buck versus LDO
  • Anything else the posting names: [topic]

Coding

  • Problems solved out loud at a whiteboard this week: [N]
  • Practiced with someone watching: [Name], [date]

Stories (STAR, 5 to 10)

  1. A failure:
  2. A conflict on a team:
  3. A hard bug:
  4. A deadline:
  5. Something I learned on my own:

Questions I will ask (at least one per interviewer)

After each round

  • How it went, for the recruiter call (went well / went poorly):
  • Questions I struggled with, to study tonight:
  • Thank-you emails sent within 24 hours to:

Linked from

Content by eeprep contributors (opens in a new tab), licensed CC BY 4.0 (opens in a new tab). Code licensed MIT (opens in a new tab). Source is in the eeprep (opens in a new tab), resume-generator (opens in a new tab), and company-lists (opens in a new tab) repositories.