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.
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.
* 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.
Sorry for the rant. I just hate addresses.
Don't even get me started on the Virgin Islands or Puerto Rico...
But for the purposes of the interview question, there are "perfectly valid" assumptions that you can make to solve the task before you. I'm not asking you to solve the entire scope of the problem -- I've been working on this for over a year with varying degrees of commitment, and I assure you I have not solved the entire scope of the problem. I don't expect you to figure it out in 15 minutes.
You can assume that there are 50 states (but that leaves out the Virgin Islands and Puerto Rico). You can assume that ZIP codes have 5 digits (but maybe someone provided all 9 digits, or maybe they left it off completely). You can assume that all streets end in a reasonable suffix (but that ignores post-directional suffixes or the examples you provided).
However, by making assumptions, you can more quickly solve the problem in an interview context. As long as I understand the assumptions you're making, I can judge the quality of your output. It won't solve everything, but maybe it's better to parse 99% of addresses using one simpler algorithm and then handle the edge cases using a second (or third, or fourth, or fifth) algorithm.
More importantly: street addressing was added to support the crude technology of the time (paper maps & phone books) -- with computers we should become MORE amenable to the vagaries and desires of humans rather than changing humans to fit the machines.
But yes, you're right. :)
From afar, it sounds like a translation of your posts are "I'm not familiar with BST, that's unfair. I'd rather a real world problem like the one I'm familiar with". As someone who never works with addresses, while reading over your various descriptions of the sub-problems I think your familiarity with the problem is clouding your judgement on the "very easily" parts, at least as compared to the original BST problem space (i.e. "someone can figure out what's necessary in ~10 mins in a high pressure situation).
Perhaps that's unfair of me but I don't see how your arbitrary problem which is fairly simple in the standard case but with a variety of interesting edge cases is any different than his problem of a similar description.
The tests I was giving involved 3 problems that were meant to be solved in 60 minutes, in front of a laptop using whatever language the developer wanted to use (I hate whiteboards myself). The interesting thing about my approach is that all 3 problems were almost impossible to solve in 60 minutes, unless the candidate had experience with algorithmic coding contests (in which case it was a question mark btw). And so I didn't expect all 3 problems to be solved for a successful interview.
1. the first problem placed in the set was always the hardest to solve. This problem didn't involve knowing specific algorithms and ideally it would be something that could be solved by brute force - it's very hard to come up with problems with this requirement btw. I had candidates choke on the first problem, trying to solve it within the big-O constraints, while ignoring everything else. This wasn't necessarily bad - one time I had this guy that approached a good solution to an otherwise very hard problem (too hard for a time-constrained interview in fact, it was an accident - advice for the wise, always solve those problems by yourself within the time constraints, before giving them to candidates). He failed to even touch the other two problems, but I liked his idea so I considered him OK. However, choking on this problem with nothing to show and failing to do anything about the other two problems was a red flag.
2. one of the problems was hand-picked to be easy enough to be solved by everybody, in a short amount of time - preferably containing the possibility of a one-off error or things like that. I never placed this as the first problem in the set of 3 - pragmatic developers that know how to prioritize their tasks, would first read all 3 problems before picking one to solve and this problem was a no brainer, while many developers tend to be hooked on the first problem failing to see there's another apple that's easier to pick (in the context of a time-constrained contest were all 3 problems are allegedly scored equally). Also, for some people I also got a hint of an ego problem - seeing that they fail to solve a hard problem, some of them gave up before the time was up, without looking at the others. Personally I don't like ego problems. Also mistakes in solving this problem were considered a red flag - for example, I expect everybody to be able to reverse an array in place on a laptop on which they can test, without any mistakes.
3. The third problem usually involved an implementation of a basic data-structure, like a HashMap. I think well rounded developers should know the data-structures they work with daily. Or maybe something else that's common, like something involving parsing. Mistakes in implementing this fully were tolerated, I only wanted to see that the developer could do it if he wanted to. Again, I never expected people to be able to solve all 3 perfectly in 60 minutes, otherwise I'd start wondering - WTF is this guy doing all day?
I could go on, but the truth is judgement was also handled on a case by case basis - I was actually trying to understand what the developer thought of while solving the problem, even though the solution was not correct or broken.