5 ms·

CTCI is a great book. Is it acceptable to ask an interviewer for a different question? For example, if you're really bad at chess algorithms and you get the N

by meggar 9y ago

CTCI is a great book. Is it acceptable to ask an interviewer for a different question? For example, if you're really bad at chess algorithms and you get the N-Queens question?

gaylemcd 9y ago
This is actually a really interesting point. (Context: In chess, a queen can move along a row, column, or diagonal to attack. The N Queens problem is to place N queens on an NxN chessboard such that no two queens can attack each other.) No one does poorly here because they are "bad at chess algorithms." They might do poorly because they think they're bad at chess algorithms. But this is not a "chess algorithm." It's an algorithm, with a chess skin. But, sure, if you're bad at chess algorithms, I'll give you this problem: Given an N by N boolean matrix (all falses), set N cells to true such that no two rows, columns, or diagonals have two trues. Same question, but with a boolean skin. Now will you be able to tackle it? So, advice: Don't assume you're bad at __ type of algorithm question. For the most part, this isn't true. At most, there's a tiny bit of knowledge to tackle it (so you're not bad at it; you just don't know something). Nearly every time I hear someone say they're bad at some type of question, it's actually just an insecurity. They aren't even missing any knowledge. The only partial exception here is recursion/dynamic programming, which does have its own little approach. At a higher level: Can you ask for a new question if you're bad at that type? You could, but it's risky. If I ask you a question that really involves pointers and you don't understand them, then okay. But realize that this might be a deal breaker for me. I might need that knowledge, or I might be concerned about the tendency to give up. You're probably better off just voicing something like: "To be honest, I haven't worked much with pointers. I'm happy to give it a shot though, unless you want to move onto a different question."
- 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.
- drenvuk 9y ago
  I have a question about the dynamic programming bit. These questions do not seem intuitive unless its one of the simple ones like, add or multiply the two previous values in the memo (fibonacci) or just check the min or max of the value and modify regarding that. Those patterns can sometimes be easy to spot. The more difficult ones feel like you absolutely have to have seen the problem before because there is complex relationship between the sub problems that are used to solve by induction/bottom up. How is someone supposed to solve these? Throwing out tons of guesses at the start feels like it'll still end up with me getting shown out before lunch time. Recursion and memoization is easy but dynamic programming doesn't really feel as natural. Ways to get better? Just do more?
  - sanjoy_das 9y ago
    > Recursion and memoization is easy but dynamic programming doesn't really feel as natural. Ways to get better? Just do more? Once you have the recursive solution, the DP solution should be fairly easy. Draw out the recursion tree for an example (or do it more generally), convert it to a DAG by combining redundant nodes, and then do a topological sort. That topological sort is the order in which you need to solve the subproblems to get a DP solution.
    - samuraijack 9y ago
      Thanks! That is quite intuitive.
  - gaylemcd 9y ago
    Basically, yes, do more. If you want to flip a memoization problem into bottom-up dynamic programming: 1. Make sure you really understand the memoization approach 2. Look at the base cases. What are the very last things the recursive approach does? 3. Build up the next case from the base case. 4. Repeat
- abc_lisper 9y ago
  I actually solved this problem in my first year of learning programming; mind you I didn't have a computer, only (limited)access to it at college. The only thing I knew was recursion. I thought hard for 3 days, discovered (he hee..) back-tracking and found the solution. For some reason, I cannot solve interview puzzles, and tried and failed to get into Google and FB.
kafkaesq 9y ago
Is it acceptable to ask an interviewer for a different question? Generally, no. Not unless you want to look like a whiny stick-in-the-mud.

by meggar 9y ago

CTCI is a great book. Is it acceptable to ask an interviewer for a different question? For example, if you're really bad at chess algorithms and you get the N-Queens question?

gaylemcd 9y ago

This is actually a really interesting point. (Context: In chess, a queen can move along a row, column, or diagonal to attack. The N Queens problem is to place N queens on an NxN chessboard such that no two queens can attack each other.) No one does poorly here because they are "bad at chess algorithms." They might do poorly because they think they're bad at chess algorithms. But this is not a "chess algorithm." It's an algorithm, with a chess skin. But, sure, if you're bad at chess algorithms, I'll give you this problem: Given an N by N boolean matrix (all falses), set N cells to true such that no two rows, columns, or diagonals have two trues. Same question, but with a boolean skin. Now will you be able to tackle it? So, advice: Don't assume you're bad at __ type of algorithm question. For the most part, this isn't true. At most, there's a tiny bit of knowledge to tackle it (so you're not bad at it; you just don't know something). Nearly every time I hear someone say they're bad at some type of question, it's actually just an insecurity. They aren't even missing any knowledge. The only partial exception here is recursion/dynamic programming, which does have its own little approach. At a higher level: Can you ask for a new question if you're bad at that type? You could, but it's risky. If I ask you a question that really involves pointers and you don't understand them, then okay. But realize that this might be a deal breaker for me. I might need that knowledge, or I might be concerned about the tendency to give up. You're probably better off just voicing something like: "To be honest, I haven't worked much with pointers. I'm happy to give it a shot though, unless you want to move onto a different question."

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.
drenvuk 9y ago
I have a question about the dynamic programming bit. These questions do not seem intuitive unless its one of the simple ones like, add or multiply the two previous values in the memo (fibonacci) or just check the min or max of the value and modify regarding that. Those patterns can sometimes be easy to spot. The more difficult ones feel like you absolutely have to have seen the problem before because there is complex relationship between the sub problems that are used to solve by induction/bottom up. How is someone supposed to solve these? Throwing out tons of guesses at the start feels like it'll still end up with me getting shown out before lunch time. Recursion and memoization is easy but dynamic programming doesn't really feel as natural. Ways to get better? Just do more?
- sanjoy_das 9y ago
  > Recursion and memoization is easy but dynamic programming doesn't really feel as natural. Ways to get better? Just do more? Once you have the recursive solution, the DP solution should be fairly easy. Draw out the recursion tree for an example (or do it more generally), convert it to a DAG by combining redundant nodes, and then do a topological sort. That topological sort is the order in which you need to solve the subproblems to get a DP solution.
  - samuraijack 9y ago
    Thanks! That is quite intuitive.
- gaylemcd 9y ago
  Basically, yes, do more. If you want to flip a memoization problem into bottom-up dynamic programming: 1. Make sure you really understand the memoization approach 2. Look at the base cases. What are the very last things the recursive approach does? 3. Build up the next case from the base case. 4. Repeat
abc_lisper 9y ago
I actually solved this problem in my first year of learning programming; mind you I didn't have a computer, only (limited)access to it at college. The only thing I knew was recursion. I thought hard for 3 days, discovered (he hee..) back-tracking and found the solution. For some reason, I cannot solve interview puzzles, and tried and failed to get into Google and FB.

kafkaesq 9y ago

Is it acceptable to ask an interviewer for a different question? Generally, no. Not unless you want to look like a whiny stick-in-the-mud.