You have been asked to interview a few candidates for an Embedded Systems Engineer opening in your group.  What would be some questions that would, in your opinion, help you identify the candidate that would be offered the job?

I understand that in a real hiring situation, the questions would be tailored to the specifics of the position to be filled, the project(s) that the new hired engineer would be expected to work on.  Is the opening for a junior or a senior level engineer?  Is it for a software or hardware engineer?  etc.

For the sake of this discussion, I'd suggest that we try to cover large.  Here's a proposal as to how you could present your question:

• Question: ...
• Level: (Junior, Intermediate, Senior...)  
• Answer: (you can choose to provide what you think is the best answer or let others try to reply with their take on the question)

Feel free to also write about why you think this is a good question to ask.

I expect most questions will be technical in nature but I am certainly opened to questions that you believe are helpful in identifying good engineers in general (character-wise).  

If this discussion thread gains momentum, it could become a very interesting and helpful read for the Embedded Systems community.  Thanks in advance for your participation!

Hi Stephane,

All of the other answers makes me think of the following anecdote.

The personel managers at Ford came up with the idea of a standardised set of questions to test IQ and aptitude in a job interview. One of the questions was; what is the value of pi. This approach of testing was high news of the day. A news reporter asked this question of Einstein and his answer was; why do you want to remember something that you can look up in a text book. 

All of you are looking for a good EE, and in my opinion doing a poor job of it.

Nr one is, if you want to interview for a system engineer position, you better make shure you have a good one on the interview team.

It starts with: What is the job of a system engineer. The tree sentence version is. This person needs to translate customer product requirements into all the forms of functional specifications (hardware, software, firmware and interface definition documents) required for an implementation. Functional specifications address WHAT needs to be implemented, NOT HOW. Therefore any questions that address detailed technical implementation knowledgement is NOT relevant. This includes anything that can be looked up on google or in a text book in less than 3 minutes is NOT Relevant. The system engineer then needs to have the ability to map the technical implementation of the functional specs onto a group of people to do the implementation (know their skills, strong points and weak points). Then guide the group to come up with a system design for the implementation where each person is guided through the design so that the team comes up with a system design and detail design, that will come together during system integration into the product. Quess what, this is once again a documentation process that the team does. Nobody is writing code or doing schematics yet.  At this point, the depth of technical knowledge and experience of the system engineer can come into play.  The knowledge of using approach X instead of approach Y will avoid pitfalls or technical difficulties, or integration difficulties, manufacturing difficulties, take less time etc.

After leading the top level design, the job of the system engineer is to lead the individuls and the team through the implementation process. Clarify specification implementation questions. Lead a team of people. (An anecdote here. Managing engineers is like herding cats, they don't flock well. And in my experience, the more skilled and clever people are, the bigger the ego and the more catty they are.) Act as an insulator between management and the team. Be an enabler for people to get their job done, on every level.

The moment the team is 4 to 5 or more people in size, the system engineer does ZERO of the technical implementation, apart from maybe what is needed for module testing, system integration and system testing. If he or she does, the system engineering tasks will suffer.

Some knowledge of ISO or other domain specifications and requirements helps. Aware of their existence, not their technical content per se.

Good people skills.

Good problem solving skills.

Good conflict resolving skills. Technical and people focused.

Good technical domain knowledge helps. This once again is not remembering the topology and calculation formulas for a specific type of opamp or filter or current source. For pete's sake.

It would take me at least a day to come up with a set of questions to test the above. And I would not be able to write down the ideal answers for them. To evaluate the answers would need the knowledge and skill of interpretation of an experienced system engineer.

In my experience, people that are technically very good, does not perform well in an interview. Your interview process needs to compensate for this. Getting a person to tell you what exites then and what they feel passioate about is a good approach, then dig deeper and deeper into that to evalute their skill and ability. Often, people that interview well becomes the bad apple in the team.

Building and maintaining technical teams are hugely important and very difficult and takes more than one project. They come together over months and years. Because basically, the leader and the team needs to build trust in each other and to respect each other and become team players.

My answer does not comply with your request, but I hope it steers you in the right direction.

Regards

Johan Hartman.

edit.

I gave myself a thumbs up by accident. Appologies.

I concur with almost everything Johan has said - it aligns with my own experience of herding cats.  

The comment about doing ZERO dev when the team reaches a certain size can be difficult when you see sub-optimal results but, yes, the system eng tasks suffer if one steps in.  Better to point out problems and suggest improvements in a manner that doesn't alienate the team member.  A life skill rather that an engineering skill.   

The comment about running interference against management is critical and I'm not sure how one would interview for such a skill.  It is a fine balancing act to keep the team's focus on accomplishing a complex task while managing expectations from customers/bosses.  A life skill rather than an engineering skill.

The interview process can be a horrible experience for the interviewee.  I recently changed jobs and went through some tough interviews.  The creepy sensation of people staring at the back of my head while I sketched state-machines and system blocks on a white board was unpleasant.  This kind of testing is mostly useless since real world engineering problems are not solved in isolation or in tiny time windows.  Unsurprisingly I ended up working for someone familiar with my work who didn't even look at my resume.

Spot-on about the interview process. The ones I *really* hate are the timed tests. I have a zero success rate. These tests are useless in what they are trying to determine. They don't test real-world knowledge and experience. (I could rant for hours.)

I am a contract engineer. I learned a long time ago, through bitter experience to ask upfront: "My understanding is the gig is to ....". I figured out half-way through interview #2 (of 3) what the gig *really* was. Didn't get it.

Part of the problem is the title "embedded systems engineer" (ESE) is a bit loose, and is not a pure "systems engineer" role. Everything jeghartman said about a "pure systems engineer" is correct and spot-on. See INCOSE.org  ...

The "embedded systems engineer" role, in my experience, is a bit of a mixed bag. Doing requirements, customer interaction, etc is part of it.

A big part is basic architecture. Embedded systems, by their nature, have a set of constraints unlike "normal" systems. A lot boils down to cost of the system, power (CPU and voltage/current), and meeting the overall system requirements. To be successful, the role demands good design skills.

Keep in mind the one important characteristic of embedded systems: limited resources. Power, flash/eeprom size, RAM size, I/O's, clock speed, often real-time requirements (miss the interrupt window && the plane crashes, etc), latency, cache impacts, run-time checks of memory bit flips and other weird cases, limited user controls (LED and two buttons - been there...), environmental extremes, physical size, etc.

Embedded systems are not mainframe apps, or desktop PCs with gobs of memory, or "in the cloud". Changing/updating/bug fixes/etc are usually non-trivial. cycling power to "fix" the problem is probably not an option.

On top of that, the ESE is probably part of a small team (in my personal experience) and has an implementation role. At a minimum, the ESE needs to be able to define the basic architecture, which demands not only good design skills, but also a good to deep knowledge of actually creating an embedded system. That is why I think implementation questions are critical.

Another reason the ESE needs to be a good engineer - so the other engineers on the team will respect them. Easier to herd the cats when they recognize the ESE has the chops. The discussions can concentrate more on style rather than "will it work?". (There probably will still be "energetic" discussions, but they will deal with technical aspects rather than personalities.)

I'll suggest "backing into" the best questions. Starting with 1> What's the largest project you've been involved in and what were your responsibilities? I'd then follow that trail to glean how much & well was the contribution. 2> What's the largest project where you were the sole or primary contributor/manager? Then follow that trail.

I suspect it wouldn't be long until it became clear if the candidate is a prime engine or a trailer. Then it returns to what you, as recruiter, are seeking for best fit.

Coincidentally I have been interviewing for Junior and Intermediate levels right now.

Obviously it is aimed at a position in our organization which is involved in the process industry with industrial interfaces and signal conditioning.

I always ask where they get new information and stay current and tied in with that what magazines/web sites they visit. (I hope for some that read sites like embeddedrelated, but the vast majority access none) (It is also a check on initiative- if they have Googled my name ahead of the interview it would show on their answers)

I show simple amplifier circuits and ask them to identify the action. One of them is always a current source.

I ask them to draw a circuit that will drive from a 5V micro output to a 24V relay using a high side driver.

I take several circuit boards and ask them to identify components (normally easier with through hole components since they are easier to see!).

Where the interviewee is familiar with micros I ask which is their favourite and why. No right answer, but it helps to identify their mindset and experience.

I pose a simple requirement like a -5V to +5V signal input and convert it to a simple output like a 0-5V and ask them how they would approach it conceptually using block diagrams etc. And then if they get it right, and I feel I want to probe further, I change the output to a current source or some other twist.

I ask them how to measure a DC and AC current.

I ask if they know what an Instrumentation Amplifier is. I f they know the answer, then they have some appropriate experience.

An I also ask for knowledge of 4-20mA. We use it a lot, and initial understanding (especially loop powered) is quite a learning curve.

I ask about documentation and their knowledge of ISO9000

I ask about how they would test a product in production and the process of implementing design for test.

Of course there is the use of software (Word Excel, Spice, etc.)

Development environments and programming language

Instruments like 'scopes, logic analyser, DMM etc.

And through this implicitly I assess their language abilities

Of course not necessarily in the above order.

Added after about 1 hr: Protocols like Modbus, EtherCAT Ethernet, etc. usage and/or design implementation

I would love to ask, but can't:

Age (younger is likelier to job hop)

Marital status/ children (commitment to the job)

What car they drive (a vintage Porsche is a no-no, based on repeated experience)

Smoker ((S)'nuff said)

It looks like you are looking for an EE who knows how to write code. Not necessarily how to write good code. I would have difficulty answering your questions, despite 40 years experience && writing many device drivers and being mentored by top EEs. But I could learn it in a reasonable amount of time. Obviously, your questions are based on your specific domain.

To the OP's question: (Modify as needed for new hire vs experienced person)

When you wake up, what do you want to do that day? Not the specifics, but the overarching goal? Looking for "Change the World".

Do they own an oscope? Which one? I would have an oscope and arduino with a PWM output. Measure the timing and duty cycle. A simple LED kit & soldering iron, PCB vise && see if they can build it.

(Looking for can they build a prototype.)

Arduino with prototype system, LED, pot, button. Blink the LED (see if they ask for the resistor...) read pot, read button. Supply them with sufficient documentation.

(looking for can they figure out a simple technical problem.)

What is your development sequence? What is a CLI? Have you written one? How many? You have a compiler but not an IDE. What do you need to load your code - what do you need? (extra points for questions about which family, JTAG, built-in boot loader, etc)

(Looking for how they approach a development task)

What micros? Favorites? strengths/weaknesses? How do you choose?

(looking for style and experience. Wanting questions about volume/cost.)

Here is a micro and a compiler, but no IDE. How do you load the code? What do you need?

(looking for low-level experience. Want questions about what tools - JTAG, etc) would work for the micro)

What is RS232, RS422, RS485 (and differences..) I2C? SPI? Ethernet sockets? Wireless?

(Looking for communications experience.)

RTOS vs bare iron? Can (and how) you use a CLI with each one? What is an ISR? How can you assure a timer ISR timing is correct? (looking for wiggling a pin.) Following that, how to measure timing of a code sequence?

(looking for backfround & experience)

OS issues: mutual exclusion? semaphore? Mutex? Difference between them? Priority inversion? interprocess communication? Stacks? How to determine stack overflow? Dynamic memory allocation vs static allocation?

(looking for knowledge of OS principles. Also useful with bare iron...)

What languages? Favorites? When are each appropriate? (assuming know C): What are the pitfalls of C? Undefined vs unspecified actions? Edge cases? What does the compiler writer get to decide about (eg is a char signed or unsigned by default.) static vars? differences in static vars? const? static const?

Asserts in C? How do they work? how to modify? How do you modify the action? Dangers of macros? When appropriate to use vs not use?

If C++, differences with C? memory management? dangers?

(looking for knowledge of the language, and the pitfalls...)

Coding standards: have you used one? which ones? Examples of good standard item (eg pick one or two out of a standard && comment.) Example of one that is bad/painful/bogus (if any). Coding style? (have them write a for() loop to walk an array). 

(looking for: do they write good code or just feel free to hack away..)

Draw me a state machine/finite automita (circles and arrows) of getting in a car and starting it. Robotic line follower (at least 2 versions, extra points for at least 3).

(The three best theory tools I use on a regular basis are: OS theory, data structures, and state machines.)

(And on this 75th anniversary of D-Day, a moment of silence please. We owe these folks so much. The first 20 minutes of Saving Private Ryan gives a (pale) idea of what it was like.)

I found very useful to not go right away to asking the classical technical/academic questions but go over their resume, paying special attention to projects the candidate expose as the more relevant.

Going over one project to another one, it results evident the projects that had played an important step in their careers. Once that 'main' experience is identified, I start asking more and more detailed questions about that specific project until comes to all light about the actual role that the candidate played and the experience they gained, then next project and so on. So, the deeper the questions are, the more I get to know the candidate skills. For example, we all know people who say out loud they have developed something but how we do know how much of that system came from themselves.

This has helped me, firstly, to contrast what their resume says against what they really learned from specific job role. Secondly, it gives me some information on how they have worked in a team.

After doing this, I usually continue the interview with tech questions based on the experience previously discussed. 

I was involved few times in the interviews of students applying for an internship. In my department we're doing only embedded software/firmware, not hardware, however we're in close contact with hardware guys to align interfaces. So my questions cover mostly software skills.

Good questions to check if the applicant does know anything about what makes embedded software special in contrast to application software is: What is the keyword "volatile" good for? What is a register? Which ways of interacting with hardware do you know?

Of course questions on experience in previous projects is interesting. Did the applicant do programming for hobby projects in the spare time? Does he/she contribute to open source projects? This gives a feeling on the programming skills.

And, not to forget: Do you have experience with configuration/version management systems? Clearcase? Git? Perforce? 

In our rather complex environment the complexity lies not only in the software to be written but also in the process. If the applicant ever worked in a larger project a rough sketch of the workflow on a whiteboard is beneficial. This also will show his skills to explain things to other people in a discussion.

The recurring question I get asked:

follow up: function may come as execute in X ticks or execute at tick Y

follow up: remove a function from scheduler

30 - 45 min whiteboard coding

variation: given a particular datasheet, use the given counters commands to build your timer, then use that for the scheduler

Oh well, it depends on what you are looking for and how is the culture at your company.

I am mostly working for startups, in places where we don't usually invest the time in extensive top-down design. Many can argue this is not how it should be done, etc, I, particularly, have pro and con arguments, but that is off-topic.

The first item in my hiring process is to define what is the profile I am looking for, the profile that matches the company or team culture, and working for startups, I ended up looking for people with high capacity to tackle multiple fronts of the project, to deal with increased systems complexity and to be able to contribute on the design - everything proven from past experience which I will discover by asking very deep and detailed questions of his past projects.

In this example I will look for: big projects participation, how many units deployed, complex problem to solve, how testing was done, which tasks or parts of the system was owned by the candidate, how did he validate his part of the code base, who were his clients, how did he serve the clients, and more.

At the end of the interview I expect to be able to classify his knowledge (which techs, how depth) and his profile (hands-on, hands-off, problem driven or task driven, shown capacity to learn).

Also I don't like to hire without seeing some code, I can offer programming challenge or read any piece of code the candidate can offer, that code will be evaluated by the best programmers in the company and I will make a review session with the candidate asking his whys, this is a rich experience, letting me to discover the development process of the candidate (test coverage, edge case handling, code organization, language features usage, over engineering)

From the coding exercise I want to rule out the bad programmers, I am not searching for great talent here, because talent in a coding exercise does not translate to success in the position.

So, I don't have specific questions to ask to test knowledge, I am more profile driven and then I set a minimum of programming skills barrier. And I have only hired for SW positions (on embedded stacks). 

The most important, in IMO, is to have a up-front check list of items you want to investigate, likely with a minimal rule out threshold defined too. And then stick to it, even if you feel the urge of opening exception. If during the hiring process you realize the list is not mature enough it is ok to update it.