Live data from Hacker News

Dark Motives and Elective Use of Brainteaser Interview Questions

onlinelibrary.wiley.com

211–220 of 300 posts

Re: Dark Motives and Elective Use of Brainteaser Interview Questions

#211

My issue is more with tricky algorithmic questions. I faced these tricky interview questions, where you either have to know the trick beforehand or there is NO way you can come up with a solution in an interview. I never understand the point of these questions. Because these esoteric hypothetical questions will almost never come up in real-life. They don't test someone's skills, because these problems don't follow an…

Exactly. An on-the-job developer who hand-rolls some tricky but well known algorithm from scratch is being foolish. It would be much more productive to see how their google-fu is.

Do they know which algorithm families to look up? Do they know which libraries in the given language will likely have the algorithms already available? That's what a real developer needs to know so why not interview for that.

Re: Dark Motives and Elective Use of Brainteaser Interview Questions

#212

I recently interviewed at Apple and one interviewer caused me to decide to never work there. I was put into a conference room and had 8 people over 6 hours come in and interview me one after another. Each person asked me about my background and then jumped into a whiteboard coding problem. Most of the interviewers were understanding of the fact that writing code on a whiteboard is nothing like writing code on a compu…

> I decided then that I never wanted to work with that person, or with other people like them.

sounds like the interview was a complete success.

As a candidate, keep in mind the most important thing you are going to get out of an interview is to assess the job and the company. They need to make a quick decision (employ you for years based on a few hours interview), and so do you.

Re: Dark Motives and Elective Use of Brainteaser Interview Questions

#213
post #10

Earlier quoted context omitted.

The theory would be that it allows the interviewee to demonstrate abstract reasoning skills, which are useful in many domains.

Also the interviewee needs to have exactly the same assumptions about the world as interviewer (or whoever come up with the brainteaser) and the knowledge of the same basic facts. I mean how do you even approach questions like -- how many snowflakes on the south pole? how many fish in all of the oceans? how much grass is in Mongolia?

I think that's the point of the question: to see how you approach it. The 'correct' approach that they'd be looking for is 'Fermi estimation': https://en.wikipedia.org/wiki/Fermi_problem

Re: Dark Motives and Elective Use of Brainteaser Interview Questions

#214

My issue is more with tricky algorithmic questions. I faced these tricky interview questions, where you either have to know the trick beforehand or there is NO way you can come up with a solution in an interview. I never understand the point of these questions. Because these esoteric hypothetical questions will almost never come up in real-life. They don't test someone's skills, because these problems don't follow an…

If I was asked to do some comp-geom problem involving convex hull algorithms or intersecting lines, I would be boned. I haven't touched any of that kind of thing years. Even something simple like a quicksort or Dijkstra's algorithm would be a challenge for me to code off the top of my head. I shouldn't have to study for a job interview, I should be interviewed on things that I do on a daily basis.

The thing with a lot of these algorithms is that they seem so obvious and simple when you know the answer, but they still took a very clever person to discover them in the first place.

A good interview question should be a question where the algorithm to implement is trivial (e.g. binary search), but the application is novel.

A good algorithm question I was asked a while ago was to reverse a string in place ("hello world => "dlrow olleh"). Then after completing this task, I was asked to reverse each word, but keep the words in order ("hello world" => "olleh dlrow").

Neither of them is a difficult algorithm. There's no specialist knowledge required to implement them, but there is a degree of logic and problem solving required.

The problem itself wasn't meant to be hard (although apparently a lot of candidates completely failed at it). It was a vehicle for me to discuss how I went about solving problems. It also ended up being a good discussion about why unit testing makes life a lot easier. My code itself was incorrect at a couple of points due to off-by-one errors, but the interviewer wasn't worried at all, because he was aware that it was a whiteboard, and these kinds of errors would be picked up in a real coding environment with testing very quickly.

Re: Dark Motives and Elective Use of Brainteaser Interview Questions

#215

Earlier quoted context omitted.

In the context that I've seen them used, the interviewer usually provides information if asked (and says so up front). e.g. if you don't know the # of inhabitants of Italy it should be completely okay to ask. In any case I don't think it is about the calculation or the final number. It's really the approach that you develop that's interesting. I've seen this mostly used in (management)consulting though, where you act…

The problem is that the interviewer asks for a number . If the question was phrased as "How would you go about finding out the GoogleAds B2B revenue in Italy for 2017, which tools and methods would you use", I'd totally go for that question. The reason is that to many people (myself included) your answer above is nonsensical. “With ~50M people capable of clicking ads, and assuming they click one ad a day at 20cnt CPC…

It's typical of people who think that a tiny amount of knowledge makes them experts in anything related to reasoning and data, as a good number of practitioners in this field do.

Re: Dark Motives and Elective Use of Brainteaser Interview Questions

#216

I recently interviewed at Apple and one interviewer caused me to decide to never work there. I was put into a conference room and had 8 people over 6 hours come in and interview me one after another. Each person asked me about my background and then jumped into a whiteboard coding problem. Most of the interviewers were understanding of the fact that writing code on a whiteboard is nothing like writing code on a compu…

> Some jobs require performance under pressure, but programming is not one of them. In fact, programming under pressure is the leading cause of programming disasters. It's the exact opposite of what a rational employer should want.

Not to defend that interviewer, but sometimes it's inevitable that you do have to code under pressure. I've been in situations where the whole system is collapsing, thousands of dollars are being lost every second, and I have to push a patch to production as quickly possible. Not that I would interview for such a situation.

Re: Dark Motives and Elective Use of Brainteaser Interview Questions

#217
post #7

As someone who does both a lot of interviewing (at Google) and gives a lot of advice on interviewing to people just starting out, this rhymes with my intuition about why some people get into interviews: even without the use of brainteasers (which, for the record, are not used at Google), the interview process is hard . People rarely come out of it without at least a twinge of frustration of humiliation. I'm not immun…

> I have a pet theory that when people interview they bring this buried frustration into the room with them and use the interviewing process to play the part of the people they feel humiliated them. I think it's possible--but there was an experiment someone ran a few years ago with a guy applying to jobs in both software development and management (while qualified for both and resumes optimized for each). One of the…

This is one of those moments where citing a source (that experiment) would be incredibly useful...

Re: Dark Motives and Elective Use of Brainteaser Interview Questions

#218

Earlier quoted context omitted.

I don't believe your nitpick is valid here. True, sometimes one has to code under pressure, in the sense that money is lost (or, at least not made) while things are down, but there's almost never a situation where you can't stop and take an extra 20 or 30 minutes to check to see that your code would do what you expect it to do. In fact, if the worst consequence of waiting 30 minutes to deploy a temporary fix is that…

I suppose we've been exposed to different parts of the software elephant. When I say money is lost... it can potentially be a lot of money. Can you imagine what 10 minutes of downtime could cost Amazon, for instance? What about streaming the superbowl? Credit card payment processors? Even something simple like the test harness for a production line may mean that an entire shift of assembly workers now has to stand id…

I understand the concept of multiplication. In such a scenario, it is even more imperative that the fix you make (temporary though it may be) actually fix things. Take the time, get all the help you need, and get it done; don’t just commit code and pray.

Re: Dark Motives and Elective Use of Brainteaser Interview Questions

#219

Earlier quoted context omitted.

> I have a pet theory that when people interview they bring this buried frustration into the room with them and use the interviewing process to play the part of the people they feel humiliated them. I think it's possible--but there was an experiment someone ran a few years ago with a guy applying to jobs in both software development and management (while qualified for both and resumes optimized for each). One of the…

This is one of those moments where citing a source (that experiment) would be incredibly useful...

I wish my Googling skills were stronger, but alas, they are not.

I remember one of the other key takeaways was that the manager role was treated more favorably--specifically that they apologized they could only offer some (reasonable) amount of relocation assistance while none was even offered in the developer role. It was theorized that managers were seen as an "in group" among other managers, but that was obviously just speculation.

I wasn't on HN at the time, so I can't confirm it was here. It was one of those blog posts / write-ups that made the rounds.

Re: Dark Motives and Elective Use of Brainteaser Interview Questions

#220
post #155

Earlier quoted context omitted.

So you met 8 people, and one of them was a jerk? I'd say that's a pretty acceptable jerk coefficient for a workplace. I've been in places north of 0.5.

The right number is zero and a UBI until they figure out how to stop being jerks. (My primary personal reason for supporting a UBI is I want to be able to say "No rational employer should employ you" without that implying "so you should be homeless and starve.") But short of that, the right number is zero on the interview circuit. You can employ jerks if you have to, but don't put them in more positions where they ha…

Just hiding how many jerks a company has until after the interview process is complete is not effectively any better - it could even be worse for people, as they could have had signal to avoid the jerk. The absence of evidence of some behavior or signal is not equivalent to it not being present at all.

In my experience, most companies have jerks - I’m not convinced it’s even avoidable reliably, as people come from many walks of life, and sometimes the walks form people to be jerks.

I work at Apple, where I’d say that jerks are a very low number of people I’ve interacted with (maybe a couple hundred employees so far) - I’ve seldom seen a company beforehand with less jerks percentage-wise, much less have processes that help with descalating arguments & deal with them quickly.

Post reply on HN