Hacker News Reader

Comment by kjgkjhfkjf | Hacker News Reader

Many interviewers ask candidates to explain their thinking. I don't think this dubious process of elimination would pass that test.

View on HN

The "algorithm" I wrote in this post is a formalized version of some problem solving techniques I picked up from the classic book "How to Solve It"[0]. In particular "working backwards". You start from the goal you want and see what you know that is applicable to getting you to goal.

[0] https://en.wikipedia.org/wiki/How_to_Solve_It

Right? When I’m interviewing I care most about the thought process and the ability to communicate in depth about something technical, the actual solution isn’t really that important at all.

This is the thought process. I use something very similar and have done well in interviews.

I found I did better in interviews when I showed my thinking less, or adapted it to the interviewer. Stating the things I'm not doing is useful, but too risky. Just hearing the words "linked list" in a problem that can't be solved with linked lists (even in the sentence "linked list doesn't seem to be right") startles some interviewers. A high enough percentage I don't want to roll that die six times during a round.

The silliest example is I like to work on problems by writing code. Yes, even if I don't understand the problem perfectly. Seeing some code helps clarify my thinking and I throw most of it away.

Freaks. People. Out.

Writing down some wrong line of code may as well be blasphemy. Strangely, not the case with comments. So my technique in interviews was to write comments that were as equivalent as possible to code and then convert it to regular code when I felt things were close enough. The biggest challenge in Python is not making it so similar that it becomes obvious what you're doing.

lol yeah having been through these loops and training to do these loops it really seems like most people say they want to see “thought process”, but what they’re really looking for are the usual cues you see in all the prep info online.

E.g. ask some clarifying questions before coding, write or suggest a brute force, and then write an optimized algo.

I find writing and even sometimes describing the brute force to be hazardous. Seems better to wave in its general direction.

Without clarifying questions, often you assume something about the problem that's not actually the case. And a brute force solution is often very useful to learn more about the problem domain. Personally I really like doing a bad solution before a better one. Especially in the setting where it's not completely whiteboard, so I have the ability to run and test my code, then having a brute force solution around to debug the problem is useful.

Narrowing the solution space makes sense. "I don't see how we can apply a DFS to this problem, so let me see if I can use a hash".

But the post does go through the thinking behind the solutions, why would this method - as it does lead to correct answers - disqualify someone?

Reply on news.ycombinator.com