7 ms·

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

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.
- spinlock 13y ago
  I've had to deal with addresses too and I think this would drive me crazy. You can't make any assumptions about addresses because they'll all be wrong eventually. Even your assumption that an address _has_ a zip code is pretty thin. Addresses in the US have zip codes. Internationally, not so much. Sorry for the rant. I just hate addresses.
  - Jemaclus 13y ago
    Haha, I know what you mean. :)
  - timbre 13y ago
    The "perfectly valid" assumption is also definitely invalid, even within the U.S. A few counterexamples in NYC: "Broadway," "The Bowery," "Avenue of the Americas." Boston has "The Fenway." Many rural addresses are in the style of "300 State Route 20."
    - gumby 13y ago
      I don't know why carmel-by-the-sea's addressing is considered odd. It was a very common system until recently (well, within the last century) and is still common in many countries. My grandmother never gave up her name for her house even when the town assigned a street number in the 1970s, and mail came just fine. 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.
      - Jemaclus 13y ago
        So, I guess I should specify that the addresses in question are United States addresses. My company operates entirely within the US and does not deal with international addresses. In this regard, Carmel is very unusual within the US. But yes, you're right. :)
    - Jemaclus 13y ago
bad_user 13y ago
First of all no interviewing method is perfect, short of working with the guy for about 2 months, unfortunately people are harder to fire. The algorithmic question you do fail at an interview is almost never the only reason for rejection (maybe the interviewer didn't like talking with you, maybe you've got some red flags on your resume, maybe he saw some samples from your GitHub account and didn't like your style, maybe he doesn't like your blog, maybe he's being a dick and you're better off without them, etc...) - plus if you interviewed at placed like Google, it's not the questions per se that makes the interview difficult, but rather the fact that they don't give a shit about losing potentially good candidates, because they can afford to. 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.

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.

spinlock 13y ago
I've had to deal with addresses too and I think this would drive me crazy. You can't make any assumptions about addresses because they'll all be wrong eventually. Even your assumption that an address _has_ a zip code is pretty thin. Addresses in the US have zip codes. Internationally, not so much. Sorry for the rant. I just hate addresses.
- Jemaclus 13y ago
  Haha, I know what you mean. :)
- timbre 13y ago
  The "perfectly valid" assumption is also definitely invalid, even within the U.S. A few counterexamples in NYC: "Broadway," "The Bowery," "Avenue of the Americas." Boston has "The Fenway." Many rural addresses are in the style of "300 State Route 20."
  - gumby 13y ago
    I don't know why carmel-by-the-sea's addressing is considered odd. It was a very common system until recently (well, within the last century) and is still common in many countries. My grandmother never gave up her name for her house even when the town assigned a street number in the 1970s, and mail came just fine. 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.
    - Jemaclus 13y ago
      So, I guess I should specify that the addresses in question are United States addresses. My company operates entirely within the US and does not deal with international addresses. In this regard, Carmel is very unusual within the US. But yes, you're right. :)
  - Jemaclus 13y ago

bad_user 13y ago

First of all no interviewing method is perfect, short of working with the guy for about 2 months, unfortunately people are harder to fire. The algorithmic question you do fail at an interview is almost never the only reason for rejection (maybe the interviewer didn't like talking with you, maybe you've got some red flags on your resume, maybe he saw some samples from your GitHub account and didn't like your style, maybe he doesn't like your blog, maybe he's being a dick and you're better off without them, etc...) - plus if you interviewed at placed like Google, it's not the questions per se that makes the interview difficult, but rather the fact that they don't give a shit about losing potentially good candidates, because they can afford to. 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.