Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Don't Want to Hire You If You Can't Reverse a Binary Tree

thecodebarbarian.com

Post reply on HN
Print view View original

91–100 of 115 posts

Re: I Don't Want to Hire You If You Can't Reverse a Binary Tree

#91

Post by dalke »

awinter-py wrote: post #78
smt88 wrote: post #47

Earlier quoted context omitted.

"To use a library effectively, you have to be able to write it." That's a blanket statement. If we find one exception to this rule, then we can say that it's 100% false (since its truthfulness is binary -- it's either true or false). To find one exception, we only need to find a single "good" piece of software whose author can't write 100% of the dependencies, including: (probably) C/C++ compilers, FS drivers, low-le…

You're not 100% wrong but you chose the wrong examples. Compilers & drivers aren't libraries. Low-level network libraries, using libuv as an example, have concurrency gotchas that require awareness on the part of the app developer. Using TCP as an example, think of the pain people go through over nagling. Security software is the best example of something we use without understanding but it has gotchas; you need a no…

"Compilers & drivers aren't libraries"? I've used LLVM as a library to just-in-time compile from Python. How is that not a library?

BTW, I've used primality testers I don't understand and couldn't implement on my own. How might I be more effective in calling is_prime()?

Re: I Don't Want to Hire You If You Can't Reverse a Binary Tree

#92

Post by cjhopman »

pessimizer wrote: post #66
x0x0 wrote: post #28

Earlier quoted context omitted.

Well, to pick on Valeri, this is simply wrong Trees are the single most important data structure in computer science. Just about everything you do in your programming career will be related to trees. Trees are a horrid data structure for any modern processor. Pointer chasing thrashes caches. The actual most important data structure is a hashmap. The same speed in theory, much faster in practice.

Everything in programming is trees. If you write a program that calls functions, that call other functions, that's a tree.

Unlikely. Unless a single function corresponds to a possibly infinite set of nodes, most programs are not trees.

Re: I Don't Want to Hire You If You Can't Reverse a Binary Tree

#93

Post by aidenn0 »

KingMob wrote: post #90
aidenn0 wrote: post #43

Earlier quoted context omitted.

Have you ever stored a dictionary inside a dictionary? (e.g. something like the JSON: {foo : {bar : "baz"}} That's a tree.

...unless it's a hashmap inside a hashmap. Or named fields in an object holding pointers that use no keys after compilation. The point being that hierarchical structures in programming languages abstract away from the underlying representation, and you can use them without knowing the details. (Though you should probably know anyway, so you understand your Big-O tradeoffs.)

A hashmap inside of a hashmap is just as much of a tree as an array inside of an array (which for a 2 element array describes a binary tree).

Re: I Don't Want to Hire You If You Can't Reverse a Binary Tree

#94

Post by [deleted] »

minimaxir wrote: post #89
gariany wrote: post #2

I lost him at: "I think homebrew is an awful piece of software that should never be used by anyone."

He clarified in the comments: > I just couldn't resist a chance to take a snipe at homebrew, because I've spent more time than I care to admit sorting through the mess junior devs, designers, and non-technical people make of their dev machines with homebrew and when it comes time to upgrade everything inevitably goes horribly wrong. The comment implies that real developers do not use Homebrew.

[deleted]

Re: I Don't Want to Hire You If You Can't Reverse a Binary Tree

#95

Post by nanis »

A long time ago, I interviewed with a major bank. As part of an all day grilling (arrive in city at 1 am, interviews start at 7:30 am, last until 6:30 pm with a lunch break), after lunch, I was given a programming task. By that time, I had already been interviewed by three people. The task was something that may have sounded trivial at first blush. I was given a computer and an hour.

After the hour was up, my code was reviewed by six people while I interviewed with the DBA who took joy in pointing out my admitted deficiencies with SQL. I then had another hour discussing the code with the six reviewers.

The program worked on the sample data I was given. I was later told that the other candidate's programs also worked on the sample data. Except, mine was the only one which actually ran to completion with their real data sets. I was also the only interviewee without a formal CS "education".

I got an offer which I ended up not taking due to location considerations.

If you are going to ask someone to write code, give them a computer and some quiet time. You can grill them about the thinking process after they came up with something. Having someone watch over one's shoulder every time one puts a pen to the stupid whiteboard will eliminate a lot more candidates for the wrong reasons than one ought to consider desirable.

Re: I Don't Want to Hire You If You Can't Reverse a Binary Tree

#96

Post by smt88 »

joslin01 wrote: post #86
smt88 wrote: post #64

Earlier quoted context omitted.

> Programmers are so sensitive, and honestly all your "sighing" is obnoxious. Perhaps instead of being annoyed, you could try to understand why people are sighing. Many of them will have lost out on a job they were qualified to do because of bullshit interviewing practices like this one. It has a real effect on them. It's not a trivial issue. > You don't have it all figured out. No one here has claimed to have it all…

I'm actually not annoyed nor do I misunderstand why people are sighing. Your emotional appeal does not hold much weight when faced with real business practices of hiring "the best" that every organization is going to strive for. I'm somehow a poor boss to work for because I told the OP his sighing is obnoxious? It is. It feigns authority and condescends the entire post for being so dumb he has to sigh at it. While yo…

> I'm actually not annoyed

Calling people obnoxious makes it sound like you were annoyed.

> Your emotional appeal does not hold much weight when faced with real business practices

People are highly emotional. Emotions explain the way people behave far better than logic does. Hiring is partially a process of selling a product (employment) to a customer with lots of options (the "best"). If you don't consider the emotional impact of your hiring practices, you'll turn off some of the "best" for no reason.

Considering and accommodating people's emotions also has a huge impact on retention, which is also incredibly important.

> considered the feelings of the guy who took the time to write up an entire post explaining his position in a rather civil & straightforward manner

No. He didn't have to write the post. He wanted people to hear him and respond, and that's what he got.

I consider the feelings of people applying for jobs because they have no other choice.

> Have you considered the person at the other end of the interview table?

I've been that person for 10 years. That's the first person whose feelings I've considered because they are my own.

Interviewing is boring, tedious, and almost impossible to turn into a repeatable process. I understand the impulse to find repeatable, objective ways to measure a candidate's abilities.

Unfortunately, people don't necessarily like being test subjects in high-pressure situations.

> Hm...

As I stated above, saying one thing about a very specific interview practice is not claiming to know everything. It's claiming to know a single, specific thing.

Re: I Don't Want to Hire You If You Can't Reverse a Binary Tree

#97

Post by smt88 »

sklogic wrote: post #84
smt88 wrote: post #22

Earlier quoted context omitted.

> knowing how to devise algorithms to accomplish a given task is a necessary competency Agreed. Why not use a realistic problem and setting?

Because realistic problems tend to be far bigger than the small, fundamental building blocks.

That's a really big obstacle, but it's not insurmountable. My companies often ask if the candidate is willing to be a contractor for a couple of weeks. If they're not currently working, it gives them some income to continue the job search, and it allows us to see what it's like working with them.

I can usually tell that someone is unacceptably bad within a few days of working with them, so it makes sense to do those few days before hiring (if possible).

Re: I Don't Want to Hire You If You Can't Reverse a Binary Tree

#98

Post by pan69 »

I think the problem with interview questions is the following;

Asking candidates about algorithmic problems is great, if that's what you're hiring for. However, what has happened over the past decade is that a lot of companies who aren't even close to solving those kind of problems (e.g. digital ad agencies, web dev & mobile app shops) have started to ask these kind of puzzle questions in their interviews because "that's what Google does" and if Google does it, well, then it must be good.

Interviewing is hard and hiring the right candidate is even harder. A lot of interviewers don't even come close to having the experience of hiring a fellow colleague. A lot of these interviewers are basically hiring themselves meaning; if the interviewer has a PhD then the candidate they're looking should also have a PhD. If the interviewer loves Haskell then the candidate should also have this quality, if the interviewer can reverse a binary tree then, well.. regardless whether or not this has any application to the position they are hiring for,

When I interview I try to look for smart people who can explain and articulate problems well. I'm looking for people who are thoughtful and have a strong sense of integrity and an absence of ego. If they can talk about building software and programming I can easily spot if they bullshit or not. Smart people can easily learn how to reserve a binary tree.

Re: I Don't Want to Hire You If You Can't Reverse a Binary Tree

#99

Post by nostrademons »

x0x0 wrote: post #28
victorhugo31337 wrote: post #4

Couldn't disagree more with the author. How many developers need to implement their own binary-tree? This is why code-bases become convoluted with six different implementations of standard data structures.

Well, to pick on Valeri, this is simply wrong Trees are the single most important data structure in computer science. Just about everything you do in your programming career will be related to trees. Trees are a horrid data structure for any modern processor. Pointer chasing thrashes caches. The actual most important data structure is a hashmap. The same speed in theory, much faster in practice.

This depends a lot on data size & shape. There've been some applications where I benchmarked a std::map (a tree, in practice) against Google's highly-tuned hashmap for a small (~25-50 item) container and the tree came out ahead. For such a small data structure, everything fit in L1 cache, and comparisons to follow pointers could usually be resolved by looking at the first word of the key.

One thing often forgotten with hashmaps is that they aren't actually O(1); they're O(k), where k is the length of the key, and often need to examine the entire key to derive a hashcode. This oftentimes makes them significantly slower than a binary search tree when the size of the key is large compared to the size of the container.

As always, measure before optimizing. YMMV.

Re: I Don't Want to Hire You If You Can't Reverse a Binary Tree

#100

Post by nostrademons »

wvenable wrote: post #25

> Trees are the single most important data structure in computer science. And yet I've never professionally had to reverse one or know if they are symmetrical.

I've had to recurse on a tree many, many times, though. Think of filesystems, DOM nodes, parse trees, control-flow graphs, nested annotations, tiered lookups, query builders, JSON structures, etc.

That's what this question is actually testing: can you decompose a problem statement, expressed in plain English, into subproblems and then solve the subproblems?

Post reply on HN