# Questions for a Software Engineering Candidate

Status
Not open for further replies.

#### Jeff Wahaus

##### Member
I've interviewed many potential software engineering candidates over the years and I have come up with a few questions which I feel can give a basic understanding of the candidates skill level. I am curious to know what questions other software engineering experts use to evaluate candidates.

If someone makes it past my basic questions I usually give them a question that I expect will trip them up a bit. I was really impressed when someone I asked in response to my trip-up question, responded with: In how many lines of code?

I am curious to know what are your trip-up questions? (don't give the answer)

#### Jeff Wahaus

##### Member
The question I asked was: Write a recursive function on the board to calculate n! (the factorial value of n).

And he wrote it in 1 line of code...

#### Jeff Wahaus

##### Member
A good question I've been asked in the past. Not really software engineering related, was: Why do they make man hole covers round? It took me a while to come up with the correct answer.

#### BobW

##### Active Member
So that they don't fall down the hole.

As for the recursive factorial problem, that's the very first example that they give in computer textbooks, when they introduce recursion. I'd be amazed if that tripped up anyone who's taken, and passed, a computer course.

The factorial problem is more efficiently solved with a loop. I'd be more inclined to pose a problem that is easiest to solve using recursion, but don't tell them that you expect them to use recursion. Then see if they figure it out on their own. One example that I can think of is generating all of the combinations or permutations of r digits out of a set of n. In math notation: nCr or nPr. For example, the list of combinations of 5 digits from a set of 8 is:
12345, 12346, 12347, 12348, 12356, 12357, 12358, 12367, 12368, 12378, 12456, 12457, 12458, 12467, 12468, 12478, 12567, 12568, 12578, 12678, 13456, 13457, 13458, 13467, 13468, 13478, 13567, 13568, 13578, 13678, 14567, 14568, 14578, 14678, 15678, 23456, 23457, 23458, 23467, 23468, 23478, 23567, 23568, 23578, 23678, 24567, 24568, 24578, 24678, 25678, 34567, 34568, 34578, 34678, 35678, 45678.

Doing this using loops is messy, but is almost trivial using recursion.

Last edited:

#### Jeff Wahaus

##### Member
As for the recursive factorial problem, that's the very first example that they give in computer textbooks, when they introduce recursion. I'd be amazed if that tripped up anyone who's taken, and passed, a computer course.
Yea, you would think. I found in practice that 9 out of 10 interview candidates couldn't answer the question or even had a clue of what was meant by recursion.

That's scary.

#### Pommie

##### Well-Known Member
That is indeed scary, any programming book will have a section on recursion and the factorial problem always the example.

I can't remember the questions we asked as it was last century when I last interviewed someone.

Mike.

#### dougy83

##### Well-Known Member
The factorial function in one line (javascript or C#):
var factorial = (n) => n>0 ? factorial(n-1) * n : 1;

One question asked at my company involves writing a function to calculate the probability of visiting a 0-cell, given a random grid of 0's and 1's, a starting coordinate, and a number of moves (along the cardinal directions) that must be taken from the starting location. The complexity should also be worked out.

#### Beau Schwabe

##### Active Member
I have been programming for nearly 42 years ... Unless you have something very application specific, I don't see the point of asking how to solve one specific function.

Instead, I would be more inclined to ask how many different programming languages a person can simultaneously program and communicate among them in a single project. This at least expresses the knowledge of a fundamental understanding of programming and a skill set difficult to master without having actual experience.

Give a scenario of a completed project you have at work and ask the new job candidate what their approach would be to come up with a solution and why they decided on certain ways to come to a solution. What kind of attention to detail was expressed during the process? Were they able to foresee possible problems along the way and come up with a fool proof solution? i.e. one of the biggest challenges to any programmer is to design something that is "idiot proof". Remember that the customers will attempt to try everything, and if your program isn't fool proof then you have a big problem.

For instance: The last three projects I have done at work, involve using a touch screen display that uses it own native language, with bidirectional communication to a micro controller. In the micro, I program in pure Assembly language, no C, Basic, or any other higher level platform flavor. I also do the PCB board layout design, and R&D for the PCB that contains the micro controller. As the project comes together, there are several hats that need to be worn not to mention a total grasp and understanding of the project.

Most of my programs are based on a dispatch style flowchart, meaning that each node is assigned an index and as a fall-through component. Each time a node is complete it changes the index and returns to the dispatch instead of going directly to the next node. This way, depending on how complex the function is, multiple flowcharts can be dispatched given that each flowchart has it's own unique index counter. This also allows for atomic functionality i.e. the water solenoid can be turned ON or OFF at any time no matter what process state the machine is in.

The flowchart method also makes it relatively easy to change and edit the method of operation .... days, months, or even years down the road if necessary.

Status
Not open for further replies.