Interview Question, What do they want to accomplish?

I was on a technical job interview today, and it was time to give me some programming exercises. I finally came to the last question:

Given the numbers:

116 104 105 115 32 105 115 32 99 111 114 114 101 99 ?

What is the next number?

To really understand开发者_Go百科 my mindset, I encourage you to stop reading, and really try to figure out what the next number is. Spend a few minutes, and if you still cannot figure it out, then read on

I first spent 5 minutes looking for a pattern, at which I didn't find any. I started to feel stupid. Mind you, the guy was staring at me, waiting for an answer. I felt kinda stupid.

So I was given a clue. This is not a mathematical question

I spent another 5 minutes, and he said The sequence is important.

Then another 5 minutes, and he said He believed only programmers would understand this

Still another 5 minutes and I had yet to understand what the last number was. He gave a final clue which allowed me to solve it, and it was Think of the numbers as replacment for some sort of Alphabet.

Now I encourage you to come up with the answer, however I also want to know from people, why would he even ask a question like this? What has this to do with programming, and what does he accomplish from seeing me using 20 minutes in desperate agony pondering?

---

First the answer: 116 - it's the decimal form of the ASCII letters "this is correc" so the letter 't' comes next.

But, while I figured out (given your clues) the pattern, I'd make a few comments:

• Presumably he was trying to see how you attacked a difficult, even nebulous problem.
• If he truly sat silent for 5 minutes at a time, then he needs to work on his interviewing style, if only to encourage you to talk.

That said:

• Did you think out loud and talk through the various approaches you used?
• Did you ask probing questions about the problem domain?

Incidentally, I mis-remembered 'a' as 96 rather than 97, so I would have missed the problem. But I would have been talking the entire time.

You have to convey your thought processes and not just come up with an answer. I've twice had interviewers give me problems that they didn't expect me to solve, both with the intent of seeing my approach to solving them.

(Incidentally, I got offers from both interviews, because I talked my way through the problems - even though I couldn't finish solving them.)

---

Anyone who writes down ascii values in decimal is insane. The sequence would look a lot more familiar if it were in hex.

---

Your question reminded me of an ad campaign of EA some years ago:

---

I have autism. Oddly, after a first glance told me it wasn't a numerical pattern, the next thing I noticed was the 32s - which I happen to know are spaces. From there I got the this/is pretty quickly (less than a minute). It's quite quick to check because the I-H and S-T codes are consecutive, I didn't know the ascii code for any of those but as soon as I'd confirmed the I-S gap fitted I knew I was on the right track.

Then the RR is rapid - one character below the S.

So - yes, I got it pretty much immediately. But, as I said, I'm autistic. There's a bucket load of normal stuff I can't do, but pattern matching is something I do compulsively. I suspect that this actually would have been unhelpful in the interview.

I know it looks like a terrible question, because it's testing your code breaking / pattern matching skills, not your problem solving skills, but I suspect that's not the intent.

When I was hiring people, I used a similar exercise which used a pack of cards with coloured shapes on and required people to sort the cards into piles, and - based on my 'fits' 'doesn't fit' answers - work out the rules of the 'game'.

The purpose of the exercise was not to test their pattern finding skills, but to get a sense of their emotional response to the experience of trying to solve a difficult problem where they will mostly run up cul-de-sacs. In my cards exercise, the cards were always presented in an order that would lead the interviewee to think they had solved it, only to find that they hadn't, three times.

For a challenging R&D role, you want to hire the people for whom the more complex the problem space becomes the more interested and excited they feel. For a less challenging role you want someone who'd rather the problem space was stable - eg someone to write queries for a large database where we don't want to change the system at all.

It's actually a pretty useful sorting exercise for matching candidates to roles.

---

So, it took me a bit, and I didn't need the hints, but 116 is the right answer. The giveaway for me wasn't so much the 32s, it was the way the numbers in the pattern repeated. There was no clear mathematical logic, but something else about the pattern clicked for me and I just got it.

Once, a long time ago, I managed to crack a game (Koronis Rift for those who care, and I never uploaded it to a BBS). I cracked it not because I wanted to copy it exactly. It was because it saved games on the same disk the game ran off of, and that really bothered me. Once I had cracked it, I was quite proud of myself because the copy protection had done something rather tricky. So I wanted to put my mark on the loading screen.

Now, I didn't know where the loading screen was. I used a disassembler to run the loading stuff, but never got as far as where the screen was loading from. But I had looked over the disk a lot, and there was a sequence of bytes that just looked like raw data for a picture. I knew how big the picture had to be if it was raw data, so I found the begin and end of the sequence, put it into a file and loaded the file up in an image editor. I was right.

Someone asked me "How did you know that was a picture?". And I was at a loss to explain. It just looked like one.

This is not a talent/skill I would expect in a good programmer. And I find interview questions that are almost expressly designed for the candidate not to get them to be really infuriating.

Yes, there is something about seeing how the candidate problem solves. But if I'm going to test that, I'm going to at least come up with a toy problem that's related to the job I want the candidate to do.

The only way I would ever ask that question is if I was looking for a reverse engineer or cryptographer. The ability to notice patterns like that and make good guesses as to what they mean would be a very valuable skill for those two roles. But not for a general programmer.

I think there is a certain sadism in some interviewers. A certain joy at seeing a candidate squirm. They might talk about looking at a candidate's problem solving ability, but I think they're really just looking to enjoy the feeling (not necessarily the actuality) of being smarter than the candidate.

---

Well, I think I've got the answer, and I got it fairly quickly - although with the help of a piece of reference material.

It does sound like a bit of a waste of time in an interview though. Certainly not something I'd ask. I agree it's something that probably only a programmer would "get" - but it doesn't indicate anything significant about the skills of that programmer.

---

Is the next number 116?

Still, "Shir ir correct" doesn't make any sense either.

Edit:

Oops!

---

I saw the 32s and that immediately clicked for me.

It could be argued that the point of the question is to see how you grope your way around a seemingly insurmountable obstacle. Did you start taking finite differences, looking for an arithmetic or polynomial sequence? Or did you just squint for a while and then shrug and give up?

Still a terrible question, in my opinion.

---

ASCII -> int ? The interviewer is crazy...

Should be 116.

Translation: this is correc

t is missing. t is 116 in the ascii table.

http://www.cs.utk.edu/~pham/ascii.html

---

Python:

>>> ''.join(map(lambda x:chr(int(x)),'116 104 105 115 32 105 115 32 99 111 114 114 101 99'.split()))
'this is correc'

The numbers appear to be ASCII codes. It's definitely not something I'd ask in an interview, though, since I don't expect anyone to know ASCII codes in decimal in an interview. Hex is a bit different (you might expect people to know that %20 is a space), but still.

---

Its ascii codes. The next letter is t. He might need you to have knowledge of the ascii codes for the job, as well as inherent ability of detecting patters.

---

I guess it's to see how you problem solve.

If you had worked it out quickly (I suspect the 32 would be a give away to those who have absorbed some ASCII codes) you probably would have a got another one of a similar type - and so on - until you found yourself outside your 'comfort zone'.

As an interviewee, these questions can be a way of detecting that a job is not for you!

---

This is ASCII code, the solution is "t" (116). However, we should pay attention to his helps, because he probably planned them.

"This is not a mathematical question" Of course it is, we have to interpret the numbers as characters and find the number which can be used to fill the blank character, so, at the end of the task you could tell him that this is very much mathematical, because you had to complete a pattern using a function.

"The sequence is important" Yes, 32 helps you to realize that he's talking about characters.

"He believed only programmers would understand this" Some non programmers also understand this, but mostly programmers understand this. He tried to point out that you can meet these numbers when you work on program codes/debugging.

"Think of the numbers as replacement for some sort of Alphabet." I'm sure you knew now the answer.

He wanted to test your inventiveness and willpower. I've met this kind of questions at IQ tests (OK, in the IQ tests they didn't appeal on ASCII characters because most of the people haven't heard of ASCII).

EDIT:

Surely, this question was planned in advance, all the helps were further clues and they were interested how much time and how many clues will be needed to decipher the sequence. However, this is a mathematical question.

---

The next number is 116.

This is a simple set of ASCII numbers, standing for the string "this is correc?". Took a bit of lookup, and the hint was in the range of numbers and the fact that 32 (space) appears.

Are you supposed to know the ASCII table by heart? This makes no sense to me as an interview question - perhaps he wanted you to identify this as an ASCII sequence.

---

Thanks for the hint with the alphabet -- it seems to be ASCII code:

numbers = [116,104,105,115,32,105,115,32,99,111,114,114,101,99]

for n in numbers:
  print "%c"%n,

gives:

t h i s   i s   c o r r e c

but without access to a computer I would not have figured out the text so fast. And I also would have spent a quite uncomfortable five minutes...

---

You know, this reminds me of a lot of math/logic exams I used to take in school, where I'd work and work at it, and finally come to what I believed was the answer they were looking for... only to feel a tremendous sense of dissatisfaction, because the question didn't really have a right answer at all. It just had an answer that was obviously supposed to be right.

I know this is kind of irrelevant to what you're asking -- yes, as others have said, the important thing was surely your thought process while attempting to solve the problem (and saying what you're thinking out loud would likely be the best strategy in this scenario) -- but frankly, if I were you, even if/when I did figure it out I wouldn't be able to resist the temptation to say:

"Look, I get that you probably want me to say 116, but why? Why does the string This is correc logically have to conclude in a t?"

I mean, think about it. The question is just, "What is the next number?" right? Not: "What is the next number, given that the sequence forms a complete statement," or: "What is the next number, assuming these are all English words," or even: "What is the next number, given that it is that last number"; it's just: "What's next?" That is so open-ended as to be unanswerable.

I wonder if the interviewer would've agreed with that logic or just gotten annoyed. Probably the latter.

---

C#:

foreach(byte b = new byte[]{116,104,105,115,32,105,115,32,99,111,114,114,101,99})
    Console.Write((char)b);

Output:

this is correc

So the answer is 116, for 't'.

---

As coders we come up against WTFs everyday: clueless clients, brain dead APIs, our own code from last week... It's just part of our industry. Knowing how well we respond to those situations is a very useful employment criterion I would think. The question itself is far less important than how you come up with an answer and justify it.

---

The correct answer is obviously 8 8 8 8 8 8 83 80 65 85 84 65 33.

---

It's 116. I didn't need your clues. Subconsciously I think I noticed all the numbers were in the 97-122 range (programming the BBC Micro 20 years ago when I was a kid helped me memorise ASCII codes for some reason!). I didn't convert each letter in my head just now, though:

>>> "".join(map(chr, [116, 104, 105, 115, 32, 105, 115, 32, 99, 111, 114, 114, 101, 99]))
'this is correc'

I guess the interviewer probably wanted to see how you think through problems, and/or thought that as a programmer you might know ASCII codes. But if this was for a senior Java developer position I'd have thought there would have been more important things to ask you. Say, for example, about data structures, or algorithms.

If they really let this go on for 20 minutes, as you say they did, they wasted a lot of time that they could have used assessing your development skills.

---

If the sequence had been in hex, I would have been able to read out the characters at a glance, at a rate of about 1-2 seconds each. I know most of the uppercase alphabet at a glance in decimal as well as all of the control characters (in terms of control-A through control-Z) and would recognize 3, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 19, 21, 26, and 27 by function. I expect part of the goal is to see whether an applicant instinctively recognizes character sequences as such. The 32 is highly suggestive of ASCII.

---

I went with more of a code breaking thought first, looking for pairs of numbers. That led me to believe it was simply substitution of numbers for characters in an alphabet. I read some books on encryption in WW2 a while ago, and some of the theories for code breaking stuck in my head.

---

The char sequence comes out to be : this is correc So 1 left is t...i.e its ascii value is 116

So answer is 116