There are merits and disadvantages to including any sort of programming challenge in your interview process. The argument for something like a FizzBuzz challenge is that a surprising number of programmers can’t actually do that, and it weeds out the worst candidates and the liars.

**Gareth** was interviewing someone who purported to be a senior developer with loads of Java experience. As a standard part of their interview process, they do a little TDD based exercise: “here’s a test, here’s how to run it, now write some code which passes the test.”

The candidate had no idea what to make of this exercise. After about 45 minutes which resulted in three lines of code (one of which was just a closing curly bracket) Gareth gave the candidate some mercy. Interviews are stressful, the candidate might not be comfortable with the tools, everybody has a bad brainfart from time to time. He offered a different, simpler task.

“Heres’s some code which generates a list of numbers. I’d like *you* to write a method which finds the number which appears in the
list most frequently.”

```
import java.io.*;
import java.util.*;
class Solution {
public static void main(String[] args) {
List<Integer> numbers = new Vector<Integer>();
numbers.add(5);
numbers.add(14);
numbers.add(6);
numbers.add(7);
numbers.add(7);
numbers.add(7);
numbers.add(20);
numbers.add(10);
numbers.add(10);
// find most common item
for(Integer num : numbers){
if(num == 5 ){
int five += 1;
}
else if(num == 14 ) [
int foue=rteen += !:
}
}
}
```

Gareth brought the interview to a close. After this, he didn’t want to spend another foue=rteen minutes trying to find a test the candidate could pass.

[Advertisement]
ProGet supports your applications, Docker containers, and third-party packages, allowing you to enforce quality standards across all components. Download and see how!

Here’s how to construct what John Horton Conway calls his “subprime fib” sequence. Seed the sequence with any two positive integers. Then at each step, sum the last two elements of the sequence. If the result is prime, append it to the sequence. Otherwise divide it by its smallest prime factor and append that.

If we start the sequence with (1, 1) we get the sequence

1, 1, 2, 3, 5, 4, 3, 7, 5, 6, 11, 17, 14, 31, 15, 23, 19, 21, 20, 41, 61, 51, 56, 107, 163, 135, 149, 142, 97, 239, 168, 37, 41, 39, 40, 79, 17, 48, 13, 61, 37, 49, 43, 46, 89, 45, 67, 56, 41, 97, 69, 83, 76, 53, 43, 48, 13, …

We know it will keep repeating because 48 followed by 13 has occurred before, and the “memory” of the sequence only stretches back two steps.

If we start with (6, 3) we get

6, 3, 3, 3, …

It’s easy to see that if the sequence ever repeats a value *n* then it will produce only that value from then on, because *n* + *n* = 2*n* is obviously not prime, and its smallest prime factor is 2.

Conway believes that this sequence will always get stuck in a cycle but this has not been proven.

Here’s Python code to try out Conway’s conjecture:

from sympy import isprime, primefactors def subprime(a, b): seq = [a, b] repeated = False while not repeated: s = seq[-1] + seq[-2] if not isprime(s): s //= primefactors(s)[0] repeated = check_repeat(seq, s) seq.append(s) return seq def check_repeat(seq, s): if not s in seq: return False if seq[-1] == s: return True # all previous occurances of the last element in seq indices = [i for i, x in enumerate(seq) if x == seq[-1]] for i in indices[:-1]: if seq[i+1] == s: return True return False

I’ve verified by brute force that the sequence repeats for all starting values less than 1000.

**Related posts**:

Next Page of Stories