is a comprehensive book on getting a job at a top tech company, while focuses on dev interviews and does this for PMs.
CareerCup's interview videos give you a real-life look at technical interviews. In these unscripted videos, watch how other candidates handle tough questions and how the interviewer thinks about their performance.
Most engineers make critical mistakes on their resumes -- we can fix your resume with our custom resume review service. And, we use fellow engineers as our resume reviewers, so you can be sure that we "get" what you're saying.
Our Mock Interviews will be conducted "in character" just like a real interview, and can focus on whatever topics you want. All our interviewers have worked for Microsoft, Google or Amazon, you know you'll get a true-to-life experience.
If we can sort both lists in memory, in takes n lg(n).
But if we can sort both lists in memory, we can sort just one list, and for the other list, for each number, just look up its complement. So, it pays to first check the list sizes and then sort the smaller one. But if neither fits in our memory of size m, we can process the shorter list in chunks of size m, each time sorting m numbers, and for each chunk of size m, process the 2nd list. This takes:
If we use a hash lookup, which is sufficient, we get: n/m (m + n)
- pending April 07, 2013So this seems to be a win. And, we can ensure there's no bad behavior in the hash, if we write our own which throws an exception when there are too many conflicts. At this point we can stop filling the hash, run the second list through it, and then iterate again.
Note that it also makes sense to ensure our hash is good for this case. I'd start out making the conflict list a linked list, then perhaps sort long ones into arrays before running the n numbers through it... On the other hand, maybe it's not worth the effort...