Egocentric flame war tech interviews

cartman82

Oh yah, that's obscure as shit. I don't think I've ever, EVER, seen HTTP PATCH used.

I think rails has a hard-on for using PATCH instead of PUT. Of course, it seems not all browsers support it, so they have to do some workaround with POST or something. All in the name of ideological purity.

jape

@blakeyrat said:

On the contrary, you're better off with someone who hasn't dug deep into the implementation of various data structures, because I can guarantee you that idiot is going to over-complicate the FUCK out of the solution.[/QUOTE]
Sure. But the guy that is going to use a hash table where a plain array would have been more than OK -- no, that guy is totally OK with you. That's not overcomplicating the solution, that's actually making it JavaScript-y!

[quote="blakeyrat, post:52, topic:3699"]The question wasn't about using them, it was about implementing them. And there's a good chance he'll never use any data structures, based on the job description. That's someone else's job.

All of the OP's 4 "self-confidence breaking" questions are about using binary trees. What made you think this was about implementing them? Maybe there is a 5th question that I am not aware of? Even my snippet above was about walking binary trees.

@blakeyrat said:

Only for C and C++ programmers. The rest of the world has moved on past those shitty languages, and implementation details like this no longer matter.[/QUOTE]
What's your favourite language? C#? Contains a LinkedList class. Java? Contains a LinkedList class. PHP? The default arrays might actually becomed linked lists in certain usecases (PHP is TRWTF of course).

Even C++ contains std::list. We are not talking about implementation details here, we are talking about how to use them and when. When is a LinkedList better than a array? When is a HashSet better than a TreeSet? etc. etc.

[quote="blakeyrat, post:52, topic:3699"]
Yup.

Look, in the 99.5% of cases where it doesn't fucking matter, then I'll implement the one that reads cleanest.

In the 0.5% of cases where it might matter, I'll 1) measure to figure out if it really matters (almost always no), and 2) maybe call some dickhead like you in to take a look.
[/QUOTE]
Ok, good luck with that on an interview. Especially when the interviewer is the "dickhead" that gets the problems solved instead of just randomly typing on the keyboard something that resembles code.

[quote="blakeyrat, post:52, topic:3699"]
If the interviewer were asking a practical question about the DOM tree, I'm guessing this post would not be on the DailyWTF. Because that'd be a sensible question for someone looking for a job in web UIs and web services.

So you're basically arguing that I need to embellish the original binary tree questions with some DOM and HTML buzzwords?
Maybe Implement a method to sum the values of all the children textboxes in a DOM tree would have made things easier for you?

"Senior Software Engineer" my ass.

Related: http://blog.codinghorror.com/why-cant-programmers-program/ (also using Discourse by the way).

blakeyrat

@jape said:

Sure. But the guy that is going to use a hash table where a plain array would have been more than OK -- no, that guy is totally OK with you. That's not overcomplicating the solution, that's actually making it JavaScript-y!

Again, I'd go with whatever has the most clarity. There's no point in moving away from whichever has the most clarity until there's a legitimate performance problem with the solution.

@jape said:

What's your favourite language? C#? Contains a LinkedList class.

Right; and it's an implementation detail that doesn't fucking matter. It's just one ICollection, IEnumerable in a sea of many, all of which can be treated interchangeably. (Which is the entire point of those Interfaces, of course.)

So if I implemented code with a List<> and hey it turns out the performance is bad, I can have some big brain like you (but hopefully one who isn't as much of an asshole) come in and just swap it out for whatever data structure works better.

@jape said:

We are not talking about implementation details here, we are talking about how to use them and when. When is a LinkedList better than a array? When is a HashSet better than a TreeSet? etc. etc.

The answer is: use the one that gives the best clarity of code. 99.5% of the time, nothing else matters.

And if you think it matters more than 0.5% of the time, you're the kind of over-architecting over-complicating idiot that I have zero patience for.

@jape said:

Ok, good luck with that on an interview. Especially when the interviewer is the "dickhead" that gets the problems solved instead of just randomly typing on the keyboard something that resembles code.

That would be an excellent answer for an interviewer. You might be the crazy one, but most people in IT agree with the "when to optimize: don't; advanced: don't yet" line of thinking.

@jape said:

Maybe Implement a method to sum the values of all the children textboxes in a DOM tree would have made things easier for you?

No, because why would you ever do that? You missed the "practical" bit of the pitch.

@jape said:

Related: http://blog.codinghorror.com/why-cant-programmers-program/ (also using Discourse by the way).

Have you read that article? Because it doesn't support your point at all.

jape

@blakeyrat said:

Again, I'd go with whatever has the most clarity. There's no point in moving away from whichever has the most clarity until there's a legitimate performance problem with the solution.

@blakeyrat said:

Right; and it's an implementation detail that doesn't fucking matter. It's just one ICollection, IEnumerable in a sea of many, all of which can be treated interchangeably.

Does... not... compute. So you say you'd go with the structure that improves code clarity the best, and yet, you mention that all of them can be treated interchangeably because they have the same interface. Thus swapping data structures, according to yourself, must not impact code clarity, because the interface is the same.

Basically you're telling me you choose the best data structure by a random guess, and if it's wrong, you call a real programmer to help in. And then yell this real programmer to go away because you have zero patience for him.

Well, it's quite the strategy.

I am sorry, are you trolling me?

boomzilla

@blakeyrat said:

You might be the crazy one, but most people in IT agree with the "when to optimize: don't; advanced: don't yet" line of thinking.

Actually, the job wanted someone with experience in something that is one of the places that requires lots of optimization:

Experience with SQL

But that doesn't have terribly much to do with traditional data structure / algorithm type analysis.

blakeyrat

@jape said:

Does... not... compute. So you say you'd go with the structure that improves code clarity the best, and yet, you mention that all of them can be treated interchangeably because they have the same interface.

You know what's hilarious? References to sci-fi series from the 1960s.

I was actually using the fact that they have the same interfaces to demonstrate the huge amount of "doesn't fucking matter" you are emanating here.

@jape said:

Basically you're telling me you choose the best data structure by a random guess, and if it's wrong, you call a real programmer to help in. And then yell this real programmer to go away because you have zero patience for him.

You're missing a step, which is by far the most important one: I actually measure performance and don't do jack if there's no performance problem.

And like I said, 99.5% of the time, there's no performance problem.

@jape said:

I am sorry, are you trolling me?

Obviously.

abarker

@jape said:

All of the OP's 4 "self-confidence breaking" questions are about using binary trees. What made you think this was about implementing them? Maybe there is a 5th question that I am not aware of? Even my snippet above was about walking binary trees.

How about the first question?

@Eldelshell said:

In this particular case the test was to write a binary tree.

That sounds like implementing. And how is this "using" instead of "implementing"?

@Eldelshell said:

- Implement a method to sum the values of all the elements in the tree.

Do it with recursion.

That second sounds like an implementation detail. Try re-reading the OP "very carefully before hitting Reply and wasting bandwidth."¹ (see what I did there?)

Bort

@jape said:

Implement a method to sum the values of all the children textboxes in a DOM tree

jQuery.

@jape said:

When is a LinkedList better than a array? When is a HashSet better than a TreeSet?

Use jQuery.

@Yamikuronue said:

I was once asked in an interview if I could name off all the HTTP actions. I came up with "POST and GET, obviously, and there's some others... I think there's DELETE, and PUT?"

You forgot jQuery.

Ragnax

@jape said:

I just can't believe that someone not able to come up on his own with a function performing a simple recursive post-order sum of a binary tree would call himself a "programmer" . It's a one liner in most languages!

Tree walking with recursion; automatic F. Unless you like to facilitate stack overflows, you perform tree walking with iteration and maintaining back state on a stack. Ofcourse, it's not a one-liner that way. But a solid algorithm implementation very rarely is.

jape

@abarker said:

How about the first question?

Ok, good point. Feel free to bring in the whip.

@abarker said:

That second sounds like an implementation detail.

No it is not. In which way does the implementation of the binary tree (and not the interface) change the implementation of a post-order walk?

@Ragnax said:

Tree walking with recursion; automatic F. Unless you like to facilitate stack overflows, you perform tree walking with iteration and maintaining back state on a stack.

Another F. You're replacing one stack with another. You have even said it so yourself!

chubertdev

You do tree walking with someone else's framework that's used heavily by other people. No need to reinvent the wheel.

jape

@chubertdev said:

You do tree walking with someone else's framework that's used heavily by other people. No need to reinvent the wheel.

Good luck trying to use someone else's tree walking framework if you don't know how to walk a binary tree.

Ragnax

@jape said:

Another F. You're replacing one stack with another. You have even said it so yourself!

A stack datastructure can (and in most cases is indeed written to) allocate on the much larger and more flexible heap. There's severly reduced risk of memory overflow occuring, to start with. Furthemore, heap allocation is a bit more flexible with regards to predicting running out of memory and performing a graceful shutdown. A stack overflow basically means your application dies a horribly screaming death in most cases.

The joke's on you if you do not understand the fundemental difference between the stack/heap allocation of a program and the stack as a data-structure.

abarker

@jape said:

No it is not. In which way does the implementation of the binary tree (and not the interface) change the implementation of a post-order walk?

Let's try this again:

The OP was told to:

@Eldelshell said:

Implement a method to sum the values of all the elements in the tree.

So he had to implement a method to sum all the tree's values. One of the details he was given for that implementation was:

@Eldelshell said:

Do it with recursion.

Hint: that's the second point in that quote in my previous post. See?

Hence the "That second sounds ..." So, I say again:

@abarker said:

Try re-reading the OP [and the post you are replying to] "very carefully before hitting Reply and wasting bandwidth."¹

Bort

@jape said:

Good luck trying to use someone else's tree walking framework if you don't know how to walk a binary tree.

The DOM is a tree.
People navigate it using j-motherfucking-Query all the time.
Most of those people don't know what a post-order walk is.
They get their work done just fine. (questionable)

That's why we're referred to as "developers" now, not "engineers".

And then the two terms became interchangeable.

EvanED

@Ragnax said:

The joke's on you if you do not understand the fundemental difference between the stack/heap allocation of a program and the stack as a data-structure.

That's why I think all functions are a sucker's bet and just use lots of gotos and global data.

(I'm not sure how serious I'm being here in my criticism of your anti-recursion point.)

jape

@Ragnax said:

A stack datastructure can (and in most cases is indeed written to) allocate on the much larger and more flexible heap. There's severly reduced risk of memory overflow occuring, to start with. Furthemore, heap allocation is a bit more flexible with regards to predicting running out of memory and performing a graceful shutdown. A stack overflow basically means your application dies a horribly screaming death in most cases.

What the fuck is a "memory overflow" here? Why is there severely reduced risk of it happening on the heap?
How can the heap "predict out of memory"?
If you run out of memory, the out of memory killer kills you. If you run out of stack, you get a invalid page fault and you get killed.
If you want to avoid either scenario, limit the rank.

@Ragnax said:

The joke's on you if you do not understand the fundemental difference
between the stack/heap allocation of a program and the stack as a
data-structure.

The worst part of all of this is that a bunch of self-admitted non-programmers is trying to prove I do not understand basic computing. This is so easy it is ridiculous.

cvi

@Ragnax said:

Tree walking with recursion; automatic F. Unless you like to facilitate stack overflows, you perform tree walking with iteration and maintaining back state on a stack. Ofcourse, it's not a one-liner that way. But a solid algorithm implementation very rarely is.

Eh? Unless your tree is insane in size, insanely badly built/balanced or your system has an insanely small stack, you must be doing something terrible if you ever even run the risk of running out of stack space. In almost all use cases normal recursion should be just fine. I mean, you can have like 100k+ nested stack frames with no problems (other than potentially doing something wrong(tm)). If your tree isn't completely nuts, that's a shitton of elements.

Sure, there are other reasons to avoid straight up recursion (it sucks in terms of perf on GPUs, but even there you'd have to do something special to run out of stack space).

Edit: I guess there's a point for using heap storage when dealing with implicit trees...

Ragnax

@cvi said:

Eh? Unless your tree is insane in size, insanely badly built/balanced or your system has an insanely small stack, you must be doing something terrible if you ever even run the risk of running out of stack space.

I agree that in general, you won't run into any issues.

However, building general purpose data structures and algorithms means you don't make assumptions on memory constraints, or if you have to make assumptions, you make them as low impact as possible. E.g., stack overflow due to recursion is pretty much damning. Failure to malloc on the heap on the other hand, can still be handled.

If jape wants to be a pedant about such things as big O notation and knowing the internals of what makes a data-structure tick, then this terrain is fair game as are his own shoddy answers.

EvanED

@jape said:

Why is there severely reduced risk of it happening on the heap?

Because the heap is orders of magnitude larger than the default stack size?

@cvi said:

Unless your tree is insane in size, insanely badly built/balanced or your system has an insanely small stack, you must be doing something terrible if you ever even run the risk of running out of stack space.

To be fair: I have actually had someone run into a (psudo) real-world stack overflow. And yes, the tree was pretty insane in size.

The difference in that case was that the process as a whole was taking dozens of gigs of memory but the stack was left around a default size, so the heap-stack proportion was way far out of whack.

jape

Ok, let me try again to explain.

Implement a method to sum the values of all the elements in the tree.

def sum(root):
  if !root: return 0
  return root.nodeValue + sum(root.firstChild) + sum(root.nextSibling)

Did you see what I did there? I (poorly) implemented a method that sums the values of a DOM node and all of its children and sister nodes.

The implementation of that is recursive.

Does that mean I know anything about the implementation details of the DOM tree I walking? Do they use a linked list? A trie? I don't know! I don't care! I just used the public interface of it.

Now. Is that different from what the OP was asked to do?

Implement a method to sum the values of all the elements in a binary tree.

def sum(root):
   if !root: return 0
   return root.nodeValue + sum(root.leftChild) + sum(root.rightChild)

I hope it's clear by now.

EvanED

@Ragnax said:

Failure to malloc on the heap on the other hand, can still be handled.

Yeah, but a lot of the it can't be handled other than just saying "uh oh, I ran out of memory... I'm quitting now!" And even more of the time, it could be handled but no one actually checks for malloc returning NULL so you'll just get a segfault anyway. And at that point you could say that you can recover gracefully from stack overflows as well just by registering the appropriate signal handler.

Bort

@jape said:

@Ragnax said:
The joke's on you if you do not understand the fundemental difference between the stack/heap allocation of a program and the stack as a data-structure.

The worst part of all of this is that a bunch of self-admitted non-programmers is trying to prove I do not understand basic computing. This is so easy it is ridiculous.

Fight! Fight! Fight!

This forum isn't big enough for both of your egos!

Arantor

Needs more @blakeyrat

jape

@EvanED said:

Yeah, but a lot of the it can't be handled other than just saying "uh oh, I ran out of memory... I'm quitting now!" And even more of the time, it could be handled but no one actually checks for malloc returning NULL so you'll just get a segfault anyway. And at that point you could say that you can recover gracefully from stack overflows as well just by registering the appropriate signal handler.

The problem is larger than that. malloc returning NULL means you've run out of address space, not necessarily physical memory. Which never happens, so most libraries just abort().

The operating system may happily kill someone else's processes long before malloc() returns NULL on your process. In fact, most systems are configured to prefer killing the most memory hungry process -- which will be yours.

Feel free to try at home. Obviously you need to dirty all pages after malloc()ing them, otherwise you will run out of address space before you do of physical memory.

jape

@Bort said:

This forum isn't big enough for both of your egos!

Don't worry, I don't have the patience to compete with TDWTF's long standing personalities.

EvanED

@jape said:

malloc returning NULL means you've run out of address space, not necessarily physical memory. Which never happens...

It certainly happens with 32-bit programs when you give them a large-enough problem, and it could well theoretically happen if malloc was smart enough to look at the current process quota you have and see you're about to reach it. (I don't know if any systems actually do this, but they could and it seems like a good idea to me for the case where what will kill you is a ulimit rather than system-wide memory use.)

Arantor

@jape said:

Don't worry, I don't have the patience to compete with TDWTF's long standing personas.

FTFY @blakeyrat isn't real, but a persona.

cvi

@Ragnax said:

General purpose data structures and algorithms mean you don't make assumptions on memory constraints, or if you have to make assumptions, you make them as low impact as possible. E.g., stack overflow due to recursion is pretty much damning. Failure to malloc on the heap on the other hand, can still be handled.

Sure, but my point is that if you ask somebody to implement a method iterating over a tree structure, and they answer with something that does recursion, that's more or less always OK and the way to go. (And not a "F".)

Now, if you specify that this is to run on some weird system with limited/no stack, or that the tree in question is somewhat insane, then it's a different issue.

But I'd still say that for 90+% cases of iterating over a standard tree, using a heap structure is overkill and unnecessary.

FrostCat

@Ragnax said:

Tree walking with recursion; automatic F. Unless you like to facilitate stack overflows

OH NOES, MEMORY IS SO DEAR HERE IN THE 80S.
OH NOES, MY LINKER DOESN'T HAVE /STACK

I mean, I take your point, but geez, you're overreacting a little. How big a tree do you need before you need to worry about stack overflow?

abarker

@jape said:

Does that mean I know anything about the implementation details of the DOM tree I walking? Do they use a linked list? A trie? I don't know! I don't care! I just used the public interface of it.

You're pulling a strawman out of your ass.

The OP was told to write a binary tree. Next, he was asked for the O of search/insert/delete on a binary tree. He was then told to implement a method for summing the values of the elements in his tree, and to make that method recursive. Finally he was asked to force his tree to be unbalanced.

There was no talk of summing on some random, unknown tree, or changing the implementation details on a random, unknown tree.

My fucking point here:

@abarker said:

That second sounds like an implementation detail.

Was that this:

@Eldelshell said:

Do it with recursion.

is an implementation detail of this:

@Eldelshell said:

Implement a method to sum the values of all the elements in the tree.

which is an add-on to this:

@Eldelshell said:

write a binary tree.

So, one final time:

@abarker said:

Try re-reading the OP [and the post you are replying to] "very carefully before hitting Reply and wasting bandwidth."

Arantor

@FrostCat said:

OH NOES, MEMORY IS SO DEAR HERE IN THE 80S.
OH NOES, MY LINKER DOESN'T HAVE /STACK

I mean, I take your point, but geez, you're overreacting a little. How big a tree do you need before you need to worry about stack overflow?

I always worry about StackOverflow. It's ruining computing.

abarker

@Arantor said:

I always worry about StackOverflow. It's ruining computing.

Hanzo'd!

jape

There was at least one older mainframe/"grid computing" software package which implemented such soft memory limits by generating a signal. Though I do believe that there may be some way to cause malloc() to return NULL "early".

FrostCat

@abarker said:

Beat me to it.

You spelled "Hanzo'd" wrong.

abarker

Better?

FrostCat

@abarker said:

Better?

Not as good as flagging me for pendantry would've been, though.

cvi

@jape said:

There was at least one older mainframe/"grid computing" software package which implemented such soft memory limits by generating a signal. Though I do believe that there may be some way to cause malloc() to return NULL "early".

If you're dealing with "special" systems (e.g., embedded with no virtual memory), it's quite possible for the implementation to actually return NULL when there's no heap space left. Though, typically people tend to avoid dynamic memory there anyway (and unbounded recursion, FWIW, because running out of stack space typically means running into and over some other memory).

jape

@abarker said:

The OP was told to write a binary tree. Next, he was asked for the O of search/insert/delete on a binary tree. He was then told to implement a method for summing the values of the elements in his tree, and to make that method recursive. Finally he was asked force his tree to be unbalanced.

i've already admitted that I skipped over the "write a binary tree" part, do you really need to rub it in my face over and over?

You're arguing that you need to know the implementation details of a binary tree in order to walk over it. Is this correct?
I've tried to show an example on why that is not true. Was the example wrong?
Where is the strawman?

You do not need to have implemented a binary tree yourself in order to walk over it. In fact, I assumed original that the OP wasn't asked to write one and yet the 4 questions still made sense. So the conclusion is that neither of the 4 questions depends on the implementation details of his binary tree.

But this discussion is getting even more ridiculous. "The implementation details of a binary tree" makes me giggle.

abarker

It was pretty minor. Not worthy of a flag.

FrostCat

@abarker said:

It was pretty minor. Not worthy of a flag.

I dunno, I thought it fit into the "needless" category. I'm not sure you should need to come up with world-shaking pendantry to qualify.

cvi

@EvanED said:

That's why I think all functions are a sucker's bet and just use lots of gotos and global data.

Actually, I just remembered that I've seen this done. Functions were used, but parameters were passed through globals. Apparently their code analysis software didn't deal too well with function parameters. (This was for a control system in cars/trucks IIRC.)

Fortunately, I didn't ever have to work with that code. Just got to enjoy looking at some folks struggling with it from distance.

abarker

@jape said:

You're arguing that you need to know the implementation details of a binary tree in order to walk over it. Is this correct?

No. That would be idiotic.

@jape said:

Where is the strawman?

You've decided that I think you must know the implementation details of a tree to walk over it, and that is the point you are arguing. There's your strawman.

I'm arguing whether the questions in the OP were about binary tree implementation. You've apparently mis-interpreted this:

@abarker said:

That second sounds like an implementation detail.

Go back and re-read all of my last post. Maybe you'll finally understand my point.

jape

Ok, so you're arguing then that it is necessary to know the implementation details of a binary tree in order to perform any of the following?

What's the O for a search/insert/delete in a binary tree?
Implement a method to sum the values of all the elements in the tree.
Do it with recursion.
Force the tree to be unbalanced.

abarker

@jape said:

Ok, so you're arguing then that it is necessary to know the implementation details of a binary tree in order to perform any of the following?

No.

Re-read this post. Carefully.

jape

Well you'll have to provide some additional explanation, cause I don't get it.

I said none of the 4 questions is about implementing binary trees.

You say the 2nd question, Implement a method to sum the values of all the elements in the tree is, because:

Do it with recursion is an implementation detail of Implement a method to sum the values of all the elements in the tree
Implement a method to sum the values of all the elements in the tree is an addon of write a binary tree

1 is true. 2 is true too, albeit it does not imply that Implement a method to sum the values of all the elements in the tree is an implementation detail of write a binary tree.

So how does one deduce Implement a method to sum the values of all the elements in the tree is about implementing binary trees from your statements?

VaelynPhi

I would have asked the OP to turn a generic tree into a binary tree, since this would be a more appropriate prelude to the eventual pain of renormalizing the database that would likely have been a requirement for the position.

I'm always amused how vehemently I can agree and disagree with @blakeyrat in a single comment of his.

Also, since it keeps me from actually having to do work for another minute or two, I'm wondering if anyone here has considered that, rather than a demonstration of some technical failure on the part of the interviewer/interviewee, that maybe the OPP is an indication of a failure of personal or social ability on their parts? I mean, if I asked someone during an interview to do some random CS101 thing and they balked, I would probably just tell them up front why I was asking, even if my reasons boiled down to "interviewing people is boring and I like fucking with people". In the position of the interviewee, however, I would be likely to, after rewriting chapter 2 of every CS book ever at the interviewer's behest, ask WTF it has to do with the job and expect a reasonable answer. (Even if that answer were, "interviewing people is boring and I like fucking with people".)

Caveat Lector: Since the job I had for three years that I really loved basically went down in flames because someone couldn't be arsed to communicate and got butthurt when projects didn't go the way he expected, I may be mildly sensitive to cases of communication breakdown.

dkf

@presidentsdaughter said:

Re-read what I said: common case. Worst case would still be O(n). If you keep a balanced tree, then worst case would also be O(log n)

I was talking about a specific, highly WTF-y implementation that I encountered over 15 years ago; I'll try to remember as many details as I can, but it was quite a while. The system concerned implemented strings as trees so that inserts and deletes of characters could be quick (AIUI, IIRC) but the code to read input built the tree like this (reading "Hello!") always:

          '!'
          /
        'o'
        /
      'l'
      /
    'l'
    /
  'e'
  /
'H'

That's pretty dumb. But what was even dumber was that when you iterated through the characters in the string (because we were trying to parse it), for each character it would start the lookup at the root instead of using a tree-traversal. That's right. Merely iterating over the characters was O(n²).

We migrated the code to (an early version of) Java. This was back in the days before JITting (we're talking Java 1.1 maybe?) so everything was still interpreted, but it still gave us many orders of magnitude speedup over the whole application because the algorithms were sane instead of being completely batshit crazy.

Checking the timeline for Java JIT engines, I see that this must've been in about 1996 or so. Damn! Nearly 20 years now…

abarker

@jape said:

So how does one deduce Implement a method to sum the values of all the elements in the tree is about implementing binary trees from your statements?

Because my statements weren't made in a vacuum, you B*****n! Because the "4 questions" that were bullet pointed can't be separated from the first one, that of writing a binary tree!

If you were to told to implement a binary tree you would start designing a binary tree object, yes?

If you were later told to add a recursive method that sums the elements in the binary tree, that method would then become an implementation detail of your binary tree object, yes?

This makes the summing method a detail of your binary tree implementation.

I am done explaining this to you. If you still don't get it, find someone else.

Edit: Fixed minor typos

jape

@abarker said:

If you were later told to add a recursive method that sums the elements in the binary tree, that method would then become an implementation detail of your binary tree object, yes?

What?? Of course not! That would be a WTF! Why would you do that? Do you know about the concepts of encapsulation, modularity, ...?

So your idea is that when you implement a data structure you also have to implement functions for every possible operation out there? Adding all the nodes? What about substracting? Multiplying? Concatenating all the nodes?????
BinaryTree.SelectRandomNodeWithAtLeastNChildrenOnTheLeft(N) ?

Obviously not. Coupling every algorithm to the implementation of your data structure is wrong. What if you decided to implement binary trees using N-ary trees, as someone above suggested? Do you have to change your sum algorithm because of that?