Venture Cup (Good Mathematical Approach to simplify a problem)
Learning From Contests
Any time you fail a problem in a contest, look at the solutions afterwards. If it uses a concept you've never heard of, learn that and solve the problem. You will almost certainly see it again somewhere.
Contests
Leetcode: Saturday 7:30 PST (1 hour 30 minutes)
Codeforces: 1-2 per week but latest is like 8am PST (2 hours)
Codechef: 1 Long Challenge (2 weekends long)
Google Code Jam: Once a year in April, but usually very fun problems.
I recommend doing the Long challenge every month, and doing Leetcode as you are in the mood. Leetcode is most representative of interview but less effective for learning. The long contest gives you time to be creative and explore lots of solutions.
It's important to not look up the answer immediately. The value in spending hours considering failing approaches is that you learn and gain an intuition for what does not work. That way, in an interview, you spend your time exploring only solutions that have potential.
Goals:
Division 1 on Codeforces or Codechef and completing the weekly Leetcode contest in < 1 hour is overkill but a good benchmark to strive for anyway.
Learning Objectives
Learn Algorithmic concepts
This is actually the least important, complicated theory questions are pretty rare in interviews. Segment Trees and Flow is like the absolute limit
Get better at coding/debugging
Debugging problems like these is very hard, and extremely costly in a programming contest. You need to learn how to identify errors quickly and gain an intuition for common edge cases.
You need to learn a programming style that minimizes code written and potential mistakes. Ex: sum all neighbors:
for (int x = 0; x < N; x++)
for (int y = 0; y < N; y++)
int sum = 0;
for (int dx = -1; dx <= 1; dx++)
for (int dy = -1; dy <= 1; dy++)
sum += inBounds(x+dx, y+dy) ? arr[x+dx][y+dy] : 0;
public boolean inBounds(int x, int y) {
return (x >= 0 && y >= 0 && x < N && y < N);
}
Having written this code many times this is way cleaner to debug than having a bunch of if statements
Articulating your thought process
Easiest way to fuckup an interview is to not say anything. You MUST explicitly say what you are thinking even if you have no idea. Most interviewers will give you useful hints so assume any hint they give you is the right answer.
There should be no dead air even when you are coding
This one is pretty tricky, but it utilizes a very important technique of working backwards. If you didn't get that one, give this one a shot: burst balloons
It's pretty common especially for Google to hide standard problems behind some logical transformation that you need to think through. In an interview you would want to be talking through your though process with your inteviewer, and they might give you hints to put you on track. Here's some more DP practice: count all valid pickup and delivery options
I hope you watched the Bitmask DP video, it's not as common in interviews, but if you can't find an optimal solution you can maybe break out the bitmask DP before moving on to something more optimized. Here's some more practice with bitmasks: maximum students taking exam
Ah the classic Binary tree problem. In java you can use a TreeMap or TreeSet. These are pretty common and you'll look like a chump if O(N) is the best you can do. Here's another one to try: minimum number of taps to open to water a garden
A binary search question was the only one I messed up on in my actual interview. I think they are pretty tough to intuit and have a lot of edge cases that are tricky to iron out without being able to run code. Here's some more binary search: find first and last position of element in sorted array
请发表评论