4 ms·

I find that for more problems you do need a trick. Once you memorize some of the main algorithms asked, usually the questions are a twist on common algorithms +

I find that for more problems you do need a trick. Once you memorize some of the main algorithms asked, usually the questions are a twist on common algorithms + some trick that is not obvious. Sure you it can become easy if you "Practice" but everything gets easier the more you do it. People who pass these either have have IQ or have grit, thats why companies use this to judge canidates, either you spent 500 hours on learning it or DS/A just sticks to your head like glue.

jaimebuelta 5y ago
the main problem is that you can get caught in an interviewing pet project, so it seems obvious for them, but not for you. Properly done, a code interview could not require clever tricks, but the problem is that it's just too easy to slip into that realm...
- iamricks 5y ago
  That's true, you can get unlucky with interviewers.
  - jonathankoren 5y ago
    The quality of the interviewer is one thing that the interviewee can’t control. The main interviewer failures are: 1) Letting the interviewer struggle. By the end of the interview, the candidate should know what the solution looks like, even if they couldn’t solve the problem themselves. If you let someone struggle too long, you’re failing them. Give feedback early. Point out caveats. Don’t have them code up a dumb a solution, and then in the last 10 minutes tell them to redo it with a completely different approach because it’s suboptimal. (Im not talking about special cars they can retrofit, or if the original wrong solution was trivial. Use your judgement.) The interviewer understands the nuances of the problem. The candidate probably doesn’t. After all, they just heard problem. 2) DO NOT CONFUSE THEM! This happens by giving the wrong feedback. You might think you’re helping someone, but you could be knocking them off their game. If they’re going for the optimal solution, and they know the approach, just let them. It’s not wrong, I’m fact it’s the most correct answer. It’s very easy to confuse someone in these timed and stressful situations. Don’t don’t do it! 3) If it’s a design question, or something else with multiple reasonable answers, then there are multiple correct answers. Make them state their assumptions. Ask how the solution would change if something was different. Don’t expect someone to come in off the street and understand the nuances of your use case and data issues. You didn’t understand them until you were confronted with the obstacles either.
jonathankoren 5y ago
Binary search Quicksort Mergesort Dijkstra’s algorthim Depth first search Breadth first search Doubly linked list Semaphores and mutexes Make sure you know the recursive versions of the algorithms, and that’s pretty much everything you ever need for a generic coding interview, and you might not even get asked a dynamic programming or a producer-consumer question. Maybe you need some more specialized data structures for a more specialized role (eg tries[0] and inverted indices, for a search job), but you probably already knew those if you were already doing that job. There’s just not that much to know. [0] https://en.wikipedia.org/wiki/Trie https://en.wikipedia.org/wiki/Trie

jaimebuelta 5y ago

the main problem is that you can get caught in an interviewing pet project, so it seems obvious for them, but not for you. Properly done, a code interview could not require clever tricks, but the problem is that it's just too easy to slip into that realm...

iamricks 5y ago
That's true, you can get unlucky with interviewers.
- jonathankoren 5y ago
  The quality of the interviewer is one thing that the interviewee can’t control. The main interviewer failures are: 1) Letting the interviewer struggle. By the end of the interview, the candidate should know what the solution looks like, even if they couldn’t solve the problem themselves. If you let someone struggle too long, you’re failing them. Give feedback early. Point out caveats. Don’t have them code up a dumb a solution, and then in the last 10 minutes tell them to redo it with a completely different approach because it’s suboptimal. (Im not talking about special cars they can retrofit, or if the original wrong solution was trivial. Use your judgement.) The interviewer understands the nuances of the problem. The candidate probably doesn’t. After all, they just heard problem. 2) DO NOT CONFUSE THEM! This happens by giving the wrong feedback. You might think you’re helping someone, but you could be knocking them off their game. If they’re going for the optimal solution, and they know the approach, just let them. It’s not wrong, I’m fact it’s the most correct answer. It’s very easy to confuse someone in these timed and stressful situations. Don’t don’t do it! 3) If it’s a design question, or something else with multiple reasonable answers, then there are multiple correct answers. Make them state their assumptions. Ask how the solution would change if something was different. Don’t expect someone to come in off the street and understand the nuances of your use case and data issues. You didn’t understand them until you were confronted with the obstacles either.

jonathankoren 5y ago

Binary search Quicksort Mergesort Dijkstra’s algorthim Depth first search Breadth first search Doubly linked list Semaphores and mutexes Make sure you know the recursive versions of the algorithms, and that’s pretty much everything you ever need for a generic coding interview, and you might not even get asked a dynamic programming or a producer-consumer question. Maybe you need some more specialized data structures for a more specialized role (eg tries[0] and inverted indices, for a search job), but you probably already knew those if you were already doing that job. There’s just not that much to know. [0] https://en.wikipedia.org/wiki/Trie https://en.wikipedia.org/wiki/Trie