4 ms·
I often do, both for fun and to prepare myself to give a question I'd like to use in an interview. The thing about interview questions at Google is there's a ve
by jfasi 8y ago
I often do, both for fun and to prepare myself to give a question I'd like to use in an interview. The thing about interview questions at Google is there's a very fine line they need to walk: if they're too easy they give no useful information about the candidate, and if they're too hard they can never be solved in 45 minutes, again yielding no useful information. You also need to be able to provide some hints, because the vast majority of candidates need a prod in the right direction now and then.
As someone with access to the entire canon of Google interview questions, I've gone through the 20 or 30 with the highest rating, and none of them are ridiculously hard. The general pattern is either 1. a coding problem, meaning a relatively easy algorithm with plenty of opportunities to screw up the implementation so we can see how well you code and how well you catch your own errors, test your code, etc and 2. an algorithms problem that's really just a dressed-up version of some basic algorithm like BFS or dynamic programming so we can see if you can make the leap from theory to application.
Obviously I'm at an advantage here because I've seen most of the questions in use today, but whenever I encounter a new one I can intuit what's being asked and what it'll take to solve. I'm sure other companies have different sorts of questions that optimize for different things, but for our questions once you do enough of them you can sort of do any of them.
--
By the way, in my experience, those seem to be the biggest pitfalls for both job candidates at Google and programmers I meet in the real world. Sure, you crammed algorithms before you came here, but can you apply them in any real-world way? Sure you know your web/mobile app framework back to front, but will you hit a wall when asked to do something novel? Sure you can write a for loop to iterate over a data set, but will you fall on your face when that data set is petabytes in size?
I've become good at Google's questions because they generally test for those two things: nitty-gritty coding skills and an ability to generalize basic algorithms. The best candidates are those who know their algorithms inside and out, have the ability to break down and transform a problem until they can apply something in their toolkit, and have the coding chops to translate their concept into an implementation. All skills which, you may notice, make for a good engineer.
If you've ever wondered why we still do whiteboard interviews, that's why. Except you can use a chromebook now if you prefer, but you get the point.
- franzwong 8y ago> Sure you can write a for loop to iterate over a data set, but will you fall on your face when that data set is petabytes in size? I also asked a question in HN yesterday. It looks like there are more questions on data structure and algorithm for big data. However, books I read don't focus much in this area. As I haven't worked on big data before, that would also be a challenge for me.
- jfasi 8y agoHere's a few pointers on big data: * You obviously need more than one machine to do computation. Things become more difficult as you go from one machine to many, so learn about parallel programming tactics like MapReduce[1] and Flume[2]. * Storing stuff is also much more difficult. You'll either be working with distributed filesystems like GFS [3] or Colossus [4], NoSQL databases like bigtable [5], or SQL-like databases like Spanner [6] and F1 [7] * Algorithms are tricky, because things that take no time at all on a single machine get to be very difficult when done on multiple machines. I don't actually know of any resources on this one, but if you know the algorithms and learn distribution tactics like I outlined above, it should make more and more sense with practice. * Finally, you need to know your operating systems and networks. What operations are cheap (RAM access, local disk access, most local computation, same-cluster network operations, streaming remote disk access) and what operations are expensive (longer network hops, random-access remote disk operations). You also should be able to ballpark (to an order of magnitude) things like latencies of operations, dataset sizes, QPS's per machine, etc. Also, when reading the papers, pay more attention to the interface than the implementation. One of the hardest things is transitioning from being spoiled by the local OS interface, where everything is cheap, to the distributed world, where seemingly random things are expensive or impossible. [1] https://static.googleusercontent.com/media/research.google.com/en//archive/mapreduce-osdi04.pdf https://static.googleusercontent.com/media/research.google.c... [2] https://ai.google/research/pubs/pub35650 https://ai.google/research/pubs/pub35650 [3] https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf https://static.googleusercontent.com/media/research.google.c... [4] https://www.systutorials.com/3202/colossus-successor-to-google-file-system-gfs/ https://www.systutorials.com/3202/colossus-successor-to-goog... [5] https://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdf https://static.googleusercontent.com/media/research.google.c... [6] https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf https://static.googleusercontent.com/media/research.google.c... [7] https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41344.pdf https://static.googleusercontent.com/media/research.google.c...