5 ms·

Do you think it makes sense to ask interviewees to solve backtracking problems, given the fact that its mostly about already knowing the solution? Someone who'

by wayn3 9y ago

Do you think it makes sense to ask interviewees to solve backtracking problems, given the fact that its mostly about already knowing the solution? Someone who's never come in contact with backtracking won't be able to solve n queens "in time", unless they pull a mathematics stunt, but those who do know backtracking won't struggle much. On a higher level - how much of an "already seen the algorithm" crapshot are tech interviews? And given the fact that a lot of the problems in your book are trivial in higher level languages (reversing a string is only hard if you somehow don't know how to do pointers) - what's your opinion on trying to use Java on a whiteboard in 2017? Has python officially become synonymous with pseudocode?

drenvuk 9y ago
It feels like the answer to both your question and mine is to do more problems. I have no issues with backtracking but your complaint mirrors my own with respect to dynamic programming. Back to leetcode I guess.
rocket_woman 9y ago
> On a higher level - how much of an "already seen the algorithm" crapshot are tech interviews? I'd say it is mostly that. Just do thirty to fifty leetcode medium problems (some of them on pen and paper), and you're good to go.
- gaylemcd 9y ago
  That is really, really not true. An unintelligent engineer will never be able to practice enough to do well on a well-conducted interview at Google. (They could in rare cases do well if all their interviewers pick common problem.)
  - logicallee 9y ago
    If it's really, really not true then why do you write >will never be able to practice enough to do well on a well-conducted interview Or in other words a true scotsman interview. It sounds like you can't bring yourself to write "on an average interview at Google" because you wish they wouldn't pick common interview problems - but they do. Based on what you just wrote, I'd certainly work through books of "interview questions". Because your phrasing just proved it works, even though ideologically that is not what candidates "should" do.
    - gaylemcd 9y ago
      No. "On an average interview at google" is not really the same thing. It's not getting at the same point. Taking a step back: If preparation can give a bad candidate a good shot at passing the interview, then that interview process is broken. If you have a company with a bad implementation of whiteboard coding interviews (for example, who just pull questions out of Cracking the Coding Interview), then it's absolutely true that a bad candidate could pass this process. This doesn't mean that whiteboard interviews are broken. It means that this company's implementation of whiteboard interviews is broken. There is a difference. For Google specifically, their implementation is decent, but not ideal. A bad candidate would have low odds of passing an average interview at Google, but those odds are not as low as I'd like.
      - logicallee 9y ago
        uh, you're willfully ignoring that we don't care about the company's side of things. In this thread where someone wrote: >> On a higher level - how much of an "already seen the algorithm" crapshot are tech interviews? >I'd say it is mostly that. Just do thirty to fifty leetcode medium problems (some of them on pen and paper), and you're good to go. Nobody in this thread cares if the reason this advice actually (in actual practice) often works is that the interview process is broken. nobody cares if the reason we get the job is because we exploited a flaw, and we "shouldn't have" done it that way. Basically, where you just wrote, >Taking a step back: If preparation can give a bad candidate a good shot at passing the interview, then that interview process is broken. you should have written: >Taking a step back: If preparation can give a bad candidate a good shot at passing the interview, then I have to admit, if you strictly want to increase your chances of getting a job, then you can do so by preparing -- but I grit my teeth while saying that, because that interview process is broken. that would have been honest and matches the reason others had for the above thread! anyway, thanks for the responses.
    - deleted 9y ago
      [deleted]
  - geebee 9y ago
    This question may be a bit too late, but I am curious. I didn't get through at Google. However, I only asked for 3 weeks to prepare, and I have outside obligations (kids, coaching, that sort of thing). I can easily traverse a binary tree, print all permutations of a set, do DFS and BFS. But I'm not super sharp, especially at a whiteboard. My review was "not bad, good analysis, but didn't make enough coding progress". Maybe they were being nice. As I said in another comment, I'm not allowed to know what my scores or reviews were. FTR, I was a math major, though I did take basic CS algorithms and data structures. So I have a background, but probably further to go than a typical CS major. I know it will vary by individual, but how many hours, over what period of time, would you say counts as "enough practice" where you might start considering that you probably aren't going to be able to practice enough to do this. Could you ballpark it? I'd prefer to avoid "unintelligent", but you know, a point at which you'd say, this probably isn't for you, might be time to get some new goals?
    - wayn3 9y ago
      a math degree with some CS is a way better background to have than being a CS major.
- UncleMeat 9y ago
  I really hope its not. I don't expect any of the people I interview to have ever seen my question or even the particular algorithmic solution before. Good candidates should be able to come up with efficient algorithms to transform and manipulate common data structures on the spot.
  - wayn3 9y ago
    Do you believe that the solutions to "solve a sudoku" and "solve n queens" are significantly different?
gaylemcd 9y ago
When I do interview training, I strongly discourage memoization / dynamic programming question. It's not that you have to have practiced this to do well. It's that you can have an okay candidate who practices it and then does well. A properly conducted technical interview will not be about having seen the algorithm before. Some companies screw it up though. But then, these same companies also screw up other parts of the interview process. I disagree that using certain languages makes a lot of problems trivial. Maybe it makes certain problem trivial, but those tend to be easier ones anyway. They're already trivial. And even if your language has a function that performs the exact thing being asked, the interviewer can easily ask you to go implement that thing. Java is fine for a whiteboard. So is python. So are most languages. No, python has not become synonymous with pseudocode. I'm not sure what you mean by that.

by wayn3 9y ago

drenvuk 9y ago

It feels like the answer to both your question and mine is to do more problems. I have no issues with backtracking but your complaint mirrors my own with respect to dynamic programming. Back to leetcode I guess.

rocket_woman 9y ago

> On a higher level - how much of an "already seen the algorithm" crapshot are tech interviews? I'd say it is mostly that. Just do thirty to fifty leetcode medium problems (some of them on pen and paper), and you're good to go.

gaylemcd 9y ago
That is really, really not true. An unintelligent engineer will never be able to practice enough to do well on a well-conducted interview at Google. (They could in rare cases do well if all their interviewers pick common problem.)
- logicallee 9y ago
  If it's really, really not true then why do you write >will never be able to practice enough to do well on a well-conducted interview Or in other words a true scotsman interview. It sounds like you can't bring yourself to write "on an average interview at Google" because you wish they wouldn't pick common interview problems - but they do. Based on what you just wrote, I'd certainly work through books of "interview questions". Because your phrasing just proved it works, even though ideologically that is not what candidates "should" do.
  - gaylemcd 9y ago
    No. "On an average interview at google" is not really the same thing. It's not getting at the same point. Taking a step back: If preparation can give a bad candidate a good shot at passing the interview, then that interview process is broken. If you have a company with a bad implementation of whiteboard coding interviews (for example, who just pull questions out of Cracking the Coding Interview), then it's absolutely true that a bad candidate could pass this process. This doesn't mean that whiteboard interviews are broken. It means that this company's implementation of whiteboard interviews is broken. There is a difference. For Google specifically, their implementation is decent, but not ideal. A bad candidate would have low odds of passing an average interview at Google, but those odds are not as low as I'd like.
    - logicallee 9y ago
      uh, you're willfully ignoring that we don't care about the company's side of things. In this thread where someone wrote: >> On a higher level - how much of an "already seen the algorithm" crapshot are tech interviews? >I'd say it is mostly that. Just do thirty to fifty leetcode medium problems (some of them on pen and paper), and you're good to go. Nobody in this thread cares if the reason this advice actually (in actual practice) often works is that the interview process is broken. nobody cares if the reason we get the job is because we exploited a flaw, and we "shouldn't have" done it that way. Basically, where you just wrote, >Taking a step back: If preparation can give a bad candidate a good shot at passing the interview, then that interview process is broken. you should have written: >Taking a step back: If preparation can give a bad candidate a good shot at passing the interview, then I have to admit, if you strictly want to increase your chances of getting a job, then you can do so by preparing -- but I grit my teeth while saying that, because that interview process is broken. that would have been honest and matches the reason others had for the above thread! anyway, thanks for the responses.
  - deleted 9y ago
    [deleted]
- geebee 9y ago
  This question may be a bit too late, but I am curious. I didn't get through at Google. However, I only asked for 3 weeks to prepare, and I have outside obligations (kids, coaching, that sort of thing). I can easily traverse a binary tree, print all permutations of a set, do DFS and BFS. But I'm not super sharp, especially at a whiteboard. My review was "not bad, good analysis, but didn't make enough coding progress". Maybe they were being nice. As I said in another comment, I'm not allowed to know what my scores or reviews were. FTR, I was a math major, though I did take basic CS algorithms and data structures. So I have a background, but probably further to go than a typical CS major. I know it will vary by individual, but how many hours, over what period of time, would you say counts as "enough practice" where you might start considering that you probably aren't going to be able to practice enough to do this. Could you ballpark it? I'd prefer to avoid "unintelligent", but you know, a point at which you'd say, this probably isn't for you, might be time to get some new goals?
  - wayn3 9y ago
    a math degree with some CS is a way better background to have than being a CS major.
UncleMeat 9y ago
I really hope its not. I don't expect any of the people I interview to have ever seen my question or even the particular algorithmic solution before. Good candidates should be able to come up with efficient algorithms to transform and manipulate common data structures on the spot.
- wayn3 9y ago
  Do you believe that the solutions to "solve a sudoku" and "solve n queens" are significantly different?

gaylemcd 9y ago

When I do interview training, I strongly discourage memoization / dynamic programming question. It's not that you have to have practiced this to do well. It's that you can have an okay candidate who practices it and then does well. A properly conducted technical interview will not be about having seen the algorithm before. Some companies screw it up though. But then, these same companies also screw up other parts of the interview process. I disagree that using certain languages makes a lot of problems trivial. Maybe it makes certain problem trivial, but those tend to be easier ones anyway. They're already trivial. And even if your language has a function that performs the exact thing being asked, the interviewer can easily ask you to go implement that thing. Java is fine for a whiteboard. So is python. So are most languages. No, python has not become synonymous with pseudocode. I'm not sure what you mean by that.