Live data from Hacker News

Inverting Binary Trees Considered Harmful

jasq.org

201–210 of 225 posts

Re: Inverting Binary Trees Considered Harmful

#201

IMHO, I feel like people who are not up to it don't agree with coding interviews. Also, in my experience, the employers that didn't check coding skills at the interview had the worst engineers I met (surprise!). Now I can see why it's easy to disagree with interviews that check your algorithms 101 knowledge: that stuff is really really rarely used in real-life and you can just google it if you ever need it. But! Keep…

>>- Can you come up with a better process that scales with the number of interviewers in your company, but also maintains reasonable consistency and keeps reasonable costs?

The last time I was looking for a job, a company gave me a small project and asked me to come back once I had finished it(or don't bother coming back). Around a week's worth time was given. The next rounds were spent around code review and discussing other ways in which the project could be completed. They basically tested my ability to get work done, and how good I was in it.

>>Maybe you think you can, but keep in mind that the tech giants have data-crunched their interview stats over and over and this process is what they stuck with.

May be you think they have it all figured out, but they routinely have to spend billions to acquire companies in order to grow. If really hired good people, they could have achieved it all in house.

>>- In places where they look for A* engineers, the point of the interview is often not to test what you know best

A* engineers ace in making things happen, not in being scholars of trivia.

>>but how you get along with problems you have never seen before.

You use your knowledge to systematically work for hours and sometimes days. Algorithms are a science that developed over decades, if some one claims they can do that over a whiteboard in an hour, they should go claim their fields medal.

>> An algorithm or data structure question often fits the bill.

What possible analytical skills can you test by knowing how well the candidate has memorized the answer to a math problem.

>>- Geeks love geeky puzzles (like inverting binary trees).

Geeks love getting stuff done, doing new things and building stuff. Not spending months memorizing math theorems.

>>Also, IMHO, knowing only one language is a red flag for me too at 10+ years experience level.

Let me guess, are you talking about people like Linus Torvalds and Theo de Raadt?

Re: Inverting Binary Trees Considered Harmful

#202

I'll be the contrarian and claim that inverting a binary tree is a perfectly reasonable interview question. (Although not anymore now that it's famous). It combines basic background knowledge (what is a binary tree and how is it structured?), ability to reason logically (binary tree algorithms are often recursive, "inverting" a tree with no children is a no-op, otherwise you want to swap the children, and the childre…

> I'll be the contrarian and claim that inverting a binary tree is a perfectly reasonable interview question. The fact that so many people in the previous discussion could not even tell what that means is a very bad sign.

I'm still not entirely sure what that means. Does it mean you recursively swap left and right branches, or does it mean you create a new data structure where the bottom elements become the top elements?

Re: Inverting Binary Trees Considered Harmful

#203
post #52

I recently interviewed for (and got) a new job. The interview process took about two weeks and on the whole was pretty reasonable for both sides. There was a short phone screen (~30 minutes) Then I had two technical exercises to do. For each, I was given a reasonable time period (4 hours) that started when I visited a special link to the get the problem description, and then used whatever tools I wanted to get it don…

>and then used whatever tools I wanted to get it done, then email in the completed exercise.

This is a much more realistic way of testing someone's skills. Asking someone to write code while they watch is not.

I am personally horrible at coding while someone is looking over my shoulder. I am just too preoccupied with their presence and the fact that they are watching. And, unless a company is still into pair programming (is anyone these days?), it's not a valid test.

Give me a real problem, reasonable time to solve it, and the tools I'd have in the real world. Then, I can show you what I can do in that same real world vs. how well I interview in some contrived format.

Re: Inverting Binary Trees Considered Harmful

#204

Earlier quoted context omitted.

> The recruiter tells you months before the interview and they (Google) even send you a list of what books and papers to read before you consider yourself ready. Right, because I have nothing better do in those months than to rehash CS 101 and waste my time inverting trees and reversing strings.

Nobody is telling you to spend all your free time on CS101 for months. It shouldn't take months. Go back, pick up an OS textbook and read a few pages without all that academic pressure. I bet you'll appreciate the writing a little more.

You totally missed the point, may be this makes sense for a few people. But a whole majority of people don't find it a very good use of their time to gain knowledge just for its own sake.

If I were writing a OS, I would bury myself in all the OS books in the world, and work atrocious hours to build one. But if you are asking me to do it, because I have to face an hour of interview 6 months from now, I find this a pointless exercise.

Re: Inverting Binary Trees Considered Harmful

#205
post #74

Earlier quoted context omitted.

While that's good advice, I don't follow it. If a company doesn't have their shit together enough to coordinate an interview schedule and get the right people into the right room at the right time with my resume in their hands, ideally in their hands ahead of time, I don't want to work there. It's a basic competence test.

"It's a basic competence test." They feel the same way about you having your own resume in an interview.

[deleted]

Re: Inverting Binary Trees Considered Harmful

#206
post #3

>You are then ushered into a room with the programmer's worst nightmare - a blank whiteboard. Am I the only one who enjoys programming interviews? Even if you screw it up, it's still fun to try your hand at whatever problem they give you. They also don't expect you to do it perfectly; you're allowed to have sub-superhuman performance.

Most posts complaining about interview process are being made by people who failed those interviews. There is a ton of reverse-survivorship bias here. It's certainly not the case that companies like GOOG/FB/MS are filled with all bozzos. If anything their interview process have been rather successful considering above average quality of talent at these companies and non-trivial products they work on. I also sense lot…

>As a programmers we are supposed to be loving these kind of CS puzzles.

I want in implementation of a high performance octree. Do it for me. Apparently you love doing this sort of thing for people who don't pay you.

Re: Inverting Binary Trees Considered Harmful

#207

I'm only a rising junior in CS on my second internship and I completely agree. I did really well in my Data Structs & Algorithms class (A+...) and I just hate these types of problems. I bombed Google and Dropbox's interviews, and am ready to never go through another process like that again if I can. I've been exceedingly lucky landing gigs at great companies that don't filter with these questions. I worked for LeadGe…

Glad you had a good experience at LeadGenius, Dan.

By the way, we're hiring: Visual Interaction Designer, Senior Product Engineer (Front End), and Senior Product Engineer

https://leadgenius.com/careers

Hope you're liking it over at GM!

Re: Inverting Binary Trees Considered Harmful

#208

I enjoy the challenge of programming interviews. When I interviewed in Mountain View, I thought it was just super cool to have been invited. It was like the mother ship had summoned me home! I was mega-underwhelmed when I botched the last session, though. And after doing so poorly, no one escorted me out or summed things up. Efficient, I suppose -- I'd met with the recruiter at the beginning of the day and there was…

I also drew a complete blank at an interview in a coding problem... and then went home an implemented it (taking quite a bit more time than I'm comfortable admitting ;-) ). Interviewing is hard (from both sides). Sometimes it just isn't your day. Sometimes it just isn't your job. I was quite depressed when I screwed up that interview because it was the first one I had done after taking 5 years away from programming p…

Unit test are not just for people who write bugs (parent comment), a good start would be to test for the 9th row the problem was asking for. Since you can't test all possible values a representative sample would be good enough.

Just to be pedantic: It's not TDD if he already wrote the functional code ;)

Re: Inverting Binary Trees Considered Harmful

#209
post #202

Earlier quoted context omitted.

> I'll be the contrarian and claim that inverting a binary tree is a perfectly reasonable interview question. The fact that so many people in the previous discussion could not even tell what that means is a very bad sign.

I'm still not entirely sure what that means. Does it mean you recursively swap left and right branches, or does it mean you create a new data structure where the bottom elements become the top elements?

Apparently it means to swap the left and right subtrees. How's that "inversion"? I'd call it "flipping" or "mirroring" or something... If this is the case, then it's a trivial solution: invert(left_child); invert(right_child);

Re: Inverting Binary Trees Considered Harmful

#210
post #112
post #89

Earlier quoted context omitted.

I think we do very well at hiring the sort of people who already work at Google. The false positive rate seems to be very low, and the people I work with mostly seem very happy (I know I certainly am). The false negative rate worries me, though, and I keep wondering if there's a way I could structure my interviews (and feedback) differently to help change that problem.

You should worry about more than the false negative rate. You should worry about the reputation Google has developed that means a lot of those who have choices opt to not even consider interviewing at Google any more because it's not worth the aggravation.

I do worry about that as well, but that's a much more difficult problem as people's opinions can be damaged by so many things along the way. What works for some people[0] is a disaster for other people. The 'disaster' nature of it can come down to not liking to be on the phone, needing answers more quickly than Google can provide them[1], or just ending up with a bad interviewer on their loop[2].

Those are much bigger issues, and there are people here trying to tackle them! I feel my effort can be best dedicated to making sure I conduct the best interviews possible. I start from by assuming my goal is to get the candidate to demonstrate the competencies we're looking for in whatever way possible. Yes, there's usually some coding. If the coding turns out to be a bit rough but the candidate can do a fantastic job of walking me through a previous project, it's design, what went well, what they would change about it now, that speaks very well of them. I can't claim they demonstrated fantastic coding, but I can claim that I think we should hire them anyway and justify that recommendation.

It's hard. I would like our process to be lighter weight (or at least, better weighted to individual candidates), but I recognize the importance of maintaining a small false positive rate. I work with really rock solid engineers, and that's one of the best things about my job. I can trust everyone around me to at least make good decisions (even if they're sometimes wrong, or they're sometimes not the decision I would have made, I can usually understand how a smart capable engineer would have made it).

[0]: My process was roughly as follows: phone screen (all technical, coding in a Google doc), on site ~3 days later (five interviews coding on a Chromebook, lunch; the usual mix of interview questions you've come to expect), offer ~5 days after that, mutual acceptance after negotiation ~3 days after that. So we're talking about two weeks end-to-end. Also, I actually really enjoy interviewing. I come out of a day of solving interview questions feeling invigorated. Like I said, we do a really good job of hiring the sort of people who already work here.

[1]: Some of the things that I think are very good about Google's process (particularly in terms of providing fairness across candidates in a way that my previous employer did not) also cause delays. A lot of effort goes into considering all of the data that's available on a candidate. The amount of discussion that goes into every candidate, even after all of the feedback is in, is staggering.

[2]: Remember that interviewers are people. We've all been told that we're representing Google, but some people take that responsibility more seriously than others. Given that interviews are typically conducted 1:1, nobody knows what happened in the room except for the interviewer and the candidate. When candidates have bad experiences, they don't necessarily report it to their recruiter, so if it's a systematic problem with a particular interviewer, unless it shows up in the feedback they're submitting, it's very difficult to detect and correct. This is really unfortunate, but of course putting two people in the room makes some candidates nervous as they feel they're being doubly judged!

Post reply on HN