[notyourloops]

It wasn't really 'trivia'. It was several hours of difficult problem solving without reference material, given access only to a whiteboard and a judge.

The studying that would have led to a success:

* Memorizing a significant amount of the interview's programming language. Since there is no reference material, you really need to know it. No standard library reference to help you out.

* Solving enough algorithms and data structures problems to be able to minimize the time needed to identify and implement them. There is a time constraint, so blanking out or slowly deriving them is a recipe for rejection.

I'm doing both of the above, and I know I'll have success this time around, but it was jarring the first time.

Honestly, I'm OK with this now, because I am good at studying and learning. I just wasn't expecting it initially, because I wasn't going in for a position at Google or something. The company advertised the position as needing much less experience than that. So I was really surprised (and under-prepared) when I was given the whole day coding interview process.

[alacombe]

> It wasn't really 'trivia'. It was several hours of difficult problem solving without reference material, given access only to a whiteboard and a judge

Even more irrelevant with today's access to Google, StackOverflow and alike. I've done my share of learning by heart pages of demonstration for some obscure quantum physic model, puking it the day of the test, and then forgetting about it. It the company is looking for an obedient monkey, well, I'll pass.

> Honestly, I'm OK with this now, because I am good at studying and learning.

But are you any good at analyzing a combination of problems never encountered before ?

[notyourloops]

> But are you any good at analyzing a combination of problems never encountered before ?

Haven't won a Nobel Prize yet, otherwise most work is done by first examining what I know vs. what I don't, and then using the appropriate tools (search, reference -> think -> implement/test -> discuss, as necessary) to accomplish the next steps.

Regardless of what I think and what I know, or even of my abilities to solve novel problems, the industry has decided upon its entrance exams.

Many times the problems vary on the surface, but the core concepts do not, and so the iterations and combinations thereof are solvable by polling previously encountered experience (study & practice).

[emodendroket]

The way to solve a problem you've not encountered is usually to break it up into smaller problems you do know how to solve, and it's easy to see how some rote learning could help here.

[sho]

OK, agreed that's not the trivia I was talking about. Although honestly it sounds like you dodged a bullet, if anything your experience is even more ridiculous. Does this company make a habit of writing programs on whiteboards without any references?

It, uh, probably does help to know the language you're being interviewed for, although a good programmer in any language can almost certainly start being productive in another one within a month. A good hiring process knows this, too.

[notyourloops]

There's knowing a programming language and where to look when you're unsure of the details, and there's knowing a programming language.

I could write programs in the target language on a computer, easily, but on a whiteboard I encountered a few halts where I would have used the reference docs. When I asked a doc reference question, I immediately could tell from facial expression alone that my interviewer was docking me points.

Was that experience ridiculous? I know it changed my willingness to interview more until I've mastered more material. I'm not going to burn time and money to be grilled for several hours and not be able to nail it.

I'm employed full time but it's time for advancement, so I've been studying a lot.