5 ms·

The "haters" section leaves out one critical reason for not doing something like this that I think is quite relevant. For those of us who have never had to do a

The "haters" section leaves out one critical reason for not doing something like this that I think is quite relevant. For those of us who have never had to do a BST before (I do not have a degree in CS, though I've been coding professionally for 8 years), expecting us to solve a BST problem in the 10, 15 minutes alotted is not really great. Even if I've never seen it before, the idea that I can solve it in 15 minutes in a high pressure environment is unrealistic. In a real world scenario, if I had to solve this kind of thing, I'd rely on existing works first. I'd google the problem, and I'd see what solutions are out there. For most problems, there's something that can point me in the right direction. For solving a BST issue from scratch in 15 minutes, well.. let's just say the first guy to come up with BSTs probably didn't come up with his solution in 15 minutes. So I would give it my best shot, but if I don't succeed, you shouldn't hold it against me. I disagree with the premise that if I can't solve this, I can't solve novel problems. That's just blatantly incorrect. I solve novel problems every day -- just not on a whiteboard and not in 15 minutes. I would much much much rather see a real-world problem. Something you've actually run into. For instance, in my line of work, I deal a lot with addresses. One of the issues that I've had to solve in the past is parsing addresses. If I give you a string of "123 Main St, Boston, MA 02123", how do you break that up into street, city, state, zip? That's something I've actually had to solve. It's something that anyone with critical thinking skills can take a decent shot at in 15 minutes. A binary search algorithm? I got a question like this one time, and I floundered because I got 90% of the way there, but I couldn't figure out how to solve one of those edge cases. The guy basically ended the interview right there, but I asked for the solution. When he gave it to me, it was something straight out of an academic textbook. I said, "Oh, you guys must use binary trees a lot." And he laughed and said, "No, never. It's low-level stuff for databases." And I just sat there, dumbstruck. Why would you give me a problem that you've never had to solve yourself? I dunno. I just disagree with the premise of the article. I think there are far better questions to ask. Problem solving in general is required -- solving academic exercises much less so.

bad_user 13y ago
As an former interviewer, I also preferred to give algorithmic problems to candidates, though I avoid the kind of problems that involve practice, such as graph stuff or dynamic programming. The rationale being that developers need to know the basics of CS, since we were into algorithms. With the mention that I didn't want to see perfect solutions, being much more interested in how the candidate approaches the problem. But yes, I agree - my only problem with real world stuff is that it is hard to come up with a set of 15 mins problems that involve analytical thinking.
- fishtoaster 13y ago
  I've heard phrases like "I wanted to see how the candidate approaches the problem" and "I want to see how they think" a lot with regards to coding questions. I'm currently working on the thesis that such phrases are nothing but hand-wavy BS to dodge real criticisms of algorithmic questions. As such, I'd be really interested to hear what constitutes good signs and bad signs in questions where you "want to see how they approach it"? What are your actual criteria?
  - Jemaclus 13y ago
    For my address problem, here's a couple of things I want to see: * You can look an address and identify the different parts * You can come up with simple ways to split up the address. Most people start off with saying "Well, there's a comma after the street and a comma after the city, and then state and ZIP have a space in between, so if I split it up like that, I have all the parts." * You can tackle more difficult addresses (i.e., What do you do if there are no commas? If someone leaves off a ZIP code?) Bonus points if you consider these things before you bring them up * Actually write an algorithm to solve it. This is a little more involved, but basically, the way you write the algorithm tells me things about what you know. If you choose to use regular expressions, that tells me you're confident enough with regular expressions to use them in an interview. If you decide to explode the string and work word by word, that tells me something else. If you decide to work left to right, right to left, etc. If you make assumptions or not, that tells me things. The great thing about addresses is that the format is pretty standard and everyone pretty much understands the nuances of it. For instance, what kind of ZIP codes are there? What are the possible values for a state? Given this knowledge, you should be able to make some assumptions and very easily figure out where State and ZIP are, or if they're even present. You'd be surprised how many people never get that far, even with hints and prompting from me. They'll stop at the comma thing, or they'll say "I'd use machine learning" like that's a magic wand of some kind. More importantly, when I introduce edge cases they hadn't considered, how do they change the algorithm? Is it a minor change, or do they have to go back to square one? Some edge cases dramatically change the entire situation. And then there are some really tricky cases. For instance, if you decide to make the (perfectly valid) assumption that streets end in a suffix (e.g., "Street", "Avenue", "Boulevard" or their abbreviations) and then decide to split the string there with the street on the left and the city/state/ZIP on the right, that sounds like a good idea. But what if it's "123 Main St W"? How does that change things? And then imagine that you have "123 Main St West Palm Beach FL"... does that West belong with the street or the city? What if there's also a "123 Main St Palm Beach FL"? How does that change things? And so on. Most of the time, people solve the simple thing. Then as I add edge cases, I want to see how they solve them. Usually this takes about 15, 20 minutes total. The best candidates wind up getting close enough to the way I did it when I first solved the problem. (I've since then solved for all of these edge cases, but that took me months.) I don't really care about the exact solution. If you get stuck at the part without commas, that's okay, I'll skip it and give another edge case. I just want to see how you think, how you solve the problem. I can teach you Python or Ruby or PHP. I can teach you the syntax necessary to parse a string. What I can't and don't have time to do is teach you how to solve problems. The programming bit is trainable. The problem solving bit... not so much.
rwallace 13y ago
In my opinion, the way the interviewer screwed up wasn't giving you that question, it was rejecting you for only getting 90% of the way there. The purpose of a simple artificial question like this is to act as a binary filter, separate people who can program (and will take a decent shot at it) from people who can't (and will just stare blankly at the board for the allotted fifteen minutes). An interviewer who starts expecting it to be more than that is just adding noise to the selection process.
- Jemaclus 13y ago
  I don't disagree with you. :)

bad_user 13y ago

As an former interviewer, I also preferred to give algorithmic problems to candidates, though I avoid the kind of problems that involve practice, such as graph stuff or dynamic programming. The rationale being that developers need to know the basics of CS, since we were into algorithms. With the mention that I didn't want to see perfect solutions, being much more interested in how the candidate approaches the problem. But yes, I agree - my only problem with real world stuff is that it is hard to come up with a set of 15 mins problems that involve analytical thinking.

fishtoaster 13y ago
I've heard phrases like "I wanted to see how the candidate approaches the problem" and "I want to see how they think" a lot with regards to coding questions. I'm currently working on the thesis that such phrases are nothing but hand-wavy BS to dodge real criticisms of algorithmic questions. As such, I'd be really interested to hear what constitutes good signs and bad signs in questions where you "want to see how they approach it"? What are your actual criteria?
- Jemaclus 13y ago
  For my address problem, here's a couple of things I want to see: * You can look an address and identify the different parts * You can come up with simple ways to split up the address. Most people start off with saying "Well, there's a comma after the street and a comma after the city, and then state and ZIP have a space in between, so if I split it up like that, I have all the parts." * You can tackle more difficult addresses (i.e., What do you do if there are no commas? If someone leaves off a ZIP code?) Bonus points if you consider these things before you bring them up * Actually write an algorithm to solve it. This is a little more involved, but basically, the way you write the algorithm tells me things about what you know. If you choose to use regular expressions, that tells me you're confident enough with regular expressions to use them in an interview. If you decide to explode the string and work word by word, that tells me something else. If you decide to work left to right, right to left, etc. If you make assumptions or not, that tells me things. The great thing about addresses is that the format is pretty standard and everyone pretty much understands the nuances of it. For instance, what kind of ZIP codes are there? What are the possible values for a state? Given this knowledge, you should be able to make some assumptions and very easily figure out where State and ZIP are, or if they're even present. You'd be surprised how many people never get that far, even with hints and prompting from me. They'll stop at the comma thing, or they'll say "I'd use machine learning" like that's a magic wand of some kind. More importantly, when I introduce edge cases they hadn't considered, how do they change the algorithm? Is it a minor change, or do they have to go back to square one? Some edge cases dramatically change the entire situation. And then there are some really tricky cases. For instance, if you decide to make the (perfectly valid) assumption that streets end in a suffix (e.g., "Street", "Avenue", "Boulevard" or their abbreviations) and then decide to split the string there with the street on the left and the city/state/ZIP on the right, that sounds like a good idea. But what if it's "123 Main St W"? How does that change things? And then imagine that you have "123 Main St West Palm Beach FL"... does that West belong with the street or the city? What if there's also a "123 Main St Palm Beach FL"? How does that change things? And so on. Most of the time, people solve the simple thing. Then as I add edge cases, I want to see how they solve them. Usually this takes about 15, 20 minutes total. The best candidates wind up getting close enough to the way I did it when I first solved the problem. (I've since then solved for all of these edge cases, but that took me months.) I don't really care about the exact solution. If you get stuck at the part without commas, that's okay, I'll skip it and give another edge case. I just want to see how you think, how you solve the problem. I can teach you Python or Ruby or PHP. I can teach you the syntax necessary to parse a string. What I can't and don't have time to do is teach you how to solve problems. The programming bit is trainable. The problem solving bit... not so much.

rwallace 13y ago

In my opinion, the way the interviewer screwed up wasn't giving you that question, it was rejecting you for only getting 90% of the way there. The purpose of a simple artificial question like this is to act as a binary filter, separate people who can program (and will take a decent shot at it) from people who can't (and will just stare blankly at the board for the allotted fifteen minutes). An interviewer who starts expecting it to be more than that is just adding noise to the selection process.

Jemaclus 13y ago
I don't disagree with you. :)