Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Solving this problem (permutations) in Haskell helped me understand the list monad, which in turn helped me think about nested-loop algorithms in general and how they should be structured in code. So thanks. It was a fun exercise and I learned something.

I am pretty sure I nailed it. But I have been asked questions like this at interviews and screwed them up (e.g., at Facebook, which asked me something very similar and I failed to get it right). The notable thing was that at home, sitting at my desk, I wasn't afraid of sitting silently and figuring it out. It took me about 3 minutes of silence for my brain to organize itself enough to solve the problem. I'm not willing to spend 3 minutes in silence at an interview, and yet if I just jumped in I would go down a lot of wrong alleys, become confused, and screw it up.

Is there room at an interview for someone to silently figure something out, without someone waiting on you, asking to "show me your thought process"?



Is there room at an interview for someone to silently figure something out...?

Frankly? No.

Not for three minutes, anyway.

That's why either (a) the permutations question is too hard, or (b) the interviewer cannot necessarily expect anyone to get the right answer, but should instead judge incidental aspects of the process. (This is what dkarl seems to be doing, and that's fine.)

If you are asked a hard question, I think it's better to steer on the side of "going down a lot of wrong alleys, out loud". Just be honest about it. If you find yourself lost, go ahead and say "oops, thinking out loud during interviews is not my strong suit and now I'm pretty sure I'm lost". Find your own bugs and laugh at them. Backtrack. Start over. Restate the problem. Sketch a unit test that describes the answer that you can't quite derive yet. Define a simpler problem that you can solve out loud, and solve that first. And, of course, always do the stupidest thing that could possibly work.

It occurs to me that the average student spends all kinds of time in school studying how to solve problems quietly and completely at one's desk, and very little time practicing the art of sketching half-baked solutions out loud while waving one's hands. But you can practice that.


"the art of sketching half-baked solutions out loud while waving one's hands"

You mean, teaching?


Precisely.


The people who did best tended to have long silences at first and get more chatty as they went on. The ones who dove right in coding and chatting did poorly. I held that against them as a sign that they would always code first and think about correctness later, which may have been unfair. Maybe I'll make "talk as you go" optional next time, in case it pressures people down the wrong path.


Not many interviewees will have the comfort level to ask the gatekeeper for some quiet time. I think interviewers should offer it proactively. Conventional wisdom in interviews is to always offer a running commentary, because people like progress bars. Particularly since an interviewer will perceive time far more slowly than the person they're grilling.

A common thought process might go something like this: inchoate thought; more structured visualizations and vague search over solution space; enough insights have accumulated; convince yourself that the solution is correct; nail down details. It's an additional skill to provide running commentary to strangers during this.

The permutations problem -- which I've encountered and did fine, FWIW -- may be a poor question for most projects. I imagine only few require much thinking along those lines.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: