Interview Prep: Unique Items in Array

by Steve Brownlee

Interviews are a necessary part of professional life. There's no way around it. Our students have the additional stress of looking forward to their very first interview for being a professional software developer - a brand, new career.

It. Is. Nerve-wracking.

Especially since poor interview processes still run rampant in our society. No one gets trained on how to conduct them, so they are left to their own devices and end up reading someone else's horrible advice online.

Now I'm not saying people should not be screened, but screening is not the same as interviewing. Nor am I saying interviewing is irrelevant, regardless of...

the many ("...slightly more chance of choosing the better of two employees ... as you would by flipping a coin.")

studies ("...most people are terrible at picking good candidates based on interviews")

and articles ("science proves interviews are pretty much hocus-pocus")

that suggest ("...not one interviewer reported noticing that he or she was conducting a random interview.")

informal interviews ("...cancelling interviews altogether. They'll save a lot of time -- and make better decisions")

are the worst ("...human connections can interfere with good decision-making")

possible option ("...interviews are the worst predictors of success on the job... and has been documented and validated by research multiple times.")

What Does Work?

Structured, unopinionated, measurable screening works. Now for software developers, making the screening about determining if they can understand the code that is directly related to the work they will be doing for their job is a fairly straightforward process.

  1. Determine what code you intend the developer to support.
  2. Identify common patterns and practices used in that code base.
  3. Define screening questions based on those patterns and practices and have the candidate discuss those during the interview based on their experience.
  4. You could even have some pre-written code and have candidate explain the code to determine understanding.
  5. Behavioral screening to determine how a candidate would handle situations she is likely to encounter during the day.

That's pretty much it.

Things to Avoid?

  1. Trivia questions. These waste everyone's time. It may be an ego boost for you, as the interviewer, but it does not help you find the best candidate.
  2. Logic puzzles like "How many golf balls fit inside the Empire State Building?". "[E]mployers assume that puzzle interviews are associated

    with cognitive ability, but there is no scientific literature to support this assertion"    . If you want to use puzzles to determine problem solving abilities, then there must be clear rules to the puzzle, such as the Cannibals and Missionaries Problem.
  3. Unstructured interviews. "Unstructured interviews can be associated with a high level of bias...". Also see all the links above.

How We Try to Help

We get feedback from students all the time about common interview questions that are asked in our community, and since everyone has to get through that process, we talk about code that will help them jump the obstacle.

One common question is to count how many times each value is in an array/list of items. Without guidance, a student would be quick to implement a nested loop strategy. To avoid unnecessary iteration, another solution is to have a lookup object that stores key/value pairs for each unique item and the number of times it appears in the collection. Using this strategy, you only need to iterate the collection one time.

const items = [6, 5, 2, 2, 5, 6, 7, 9, 0, 8, 2, 67, 5, 4, 3, 12, 2, 3, 4, 2, 2, 2, 5, 5, 6, 7, 78, 8, 9, 9, 90]

const finalTable = items.reduce((map, currentItem) => {
    map.has(currentItem) 
        ? map.set(currentItem, map.get(currentItem) + 1) 
        : map.set(currentItem, 1)
    return map
}, new Map())

This is one of many exercises that we show students to help them during their interview process. It makes me feel like we're "teaching to the test" - which I despise - but since the students always come first at Nashville Software School, then that's what I'll do.

My plan to is to keep collecting data and start publishing articles that my students can reference after they graduate to keep their skills sharp and have answers to common questions fresh in their minds.