Hacker News Reader

Comment by glangdale | Hacker News Reader

I feel this way too. Someone once told me about their Google interview and mentioned one of the problems. I spent a fruitless 20 mins flailing around trying for a good solution, then stopped thinking about it. 5 hours later on public transit the entire (and, as it happens, perfect) solution popped, unbidden, into my head.

I always thought that would have been particularly galling if it had been my interview...

View on HN

I just had a Google technical phone interview. I won't divulge the question but it was related to a design pattern that JavaScript developers use every day in frameworks like Vue/React, yet probably never had to program from scratch. I identified the pattern, described the API correctly, but then I had to implement the API and that's when I knew I was finished. Evidently my intuition of how it should be implemented was also correct, but I started stumbling on relatively minor things (structure of a JSON object) because I didn't have the time I needed to develop an extremely clear mental image of what the details of the solution looked like and I had to keep coding anyway. I'm certain that 20-30 minutes alone would have been sufficient to develop a working proof of concept.

After the interview I ran the problem by a couple very senior front end devs at fang companies and they wouldn't have gotten it either. Before the rejection I thought I might be ok - it's not about getting it correct, they say, it's about the process - but slow thinking is a very real problem in the context of interviews like this.

Also relevant: the French have a great phrase for this - https://en.wikipedia.org/wiki/L%27esprit_de_l%27escalier

Ha. Remembering that one. Is there something about the French language that lends itself more easily to great wit and very usable idioms?

There's nothing language-specific about that idiom. In English, it's staircase wit. It should work in most languages as long as you have the story to go with it.

Those questions are horrible. They have almost no signal, I interview a ton of people and I ask much much simpler questions, a question that starts easy and can be made more complex is best. I used to ask stupid hard questions and I have matured.

It was a great question in terms of something you might work through in classroom setting for advanced undergraduates or beyond. I thought it was really interesting. However, I think the weakness of it would be that anyone with a particular background (out-of-core) would identify it immediately. Many of the "hard questions" really come down to being some shibboleth to identify who has been at the right schools. :-) (and that's not a particularly sour note from me, as I have a CMU PhD, although I still can't get those questions)

> shibboleth to identify

Exactly. And it sickens me. I'd like the resumes to be scrubbed, zero knowledge of the school someone went to. I see dynamic programming problems used for the same, either you have had them in an academic setting or you probably going in blind.

A more humane and useful questions starts off easy, if they get that, add in extra conditions to make it more difficult and extract more signal. Almost any easy questions can from duh to omg in a handful of criteria.

I had an interview question like that once. I managed to come up with an ugly-but-passable solution at the time.

Later that evening a much better solution occurred to me so I coded it up and emailed it to the interviewers.

I got an offer the next morning.

Archimedes would be proud.

Reply on news.ycombinator.com