A Quantum Immortal

When I started to think seriously about working for Google, I knew I had to get back into shape, fast. Google were going to test me in their (in)famous interview process, which puts a lot of emphasis on basic, “hardcore” computer science – namely, data structures and algorithms.

In the course of the recent months, I have solved quite a few problems in “classic CS” (all of which have classic textbook solutions), and coded the test cases and my solutions. I would like to share this codebase with you on Github.

Basic contains various exercises, algorithms and data structures, implemented in java. Some problems that are included are:

• The Selection Problem (finding a median or the K-th largest value)
• The Knapsack Problem (NP-complete, but can still be solved for small N)
• Writing a synchronous/blocking queue
• Various Google Code Jam problems, which essentially boil down to stuff like Dijkstra, Dynamic Programming, and Binary Search
• Data structures such as Graphs, Hashmaps, Binary Heaps, and Linked Lists
• Various sorting algorithms including Bubble Sort, Heap Sort, Quick Sort (the 3-quicksort varient, which I found easier to implement correctly), and of course Merge Sort
• Binary trees and B-Trees
• A various other riddles, including some from the wonderful site ihas1337code.

Since the purpose of writing this code was more internal than external, the level of documentation and finish is not perfect. Some tests are failing, and the code has some undiscovered bugs. Still, I think that it’s a worthy reference that can be improved in the future. Naturally, many/all of the above algorithms have better, more professional implementations (some of these are in the JDK itself). However, Basic has the advantage that it does not try to be a complete, production implementation, and thus might be simpler than some of the more complex/complete implementations.

I hope you will find it useful – although I encourage you to use the test harness only at first, and write your own implementations. You learn much more from writing code than from reading it. If you have any questions, or want me to add a specific piece of documentation, feel free to ask.

It’s been three years since I joined Delver. Three years, and three different positions in two companies (Delver and Sears Israel). There must be some lessons I can think of from this period, right?

• If you want to build a web search engine, you have to think big (and raise a lot of money). Note – lots of money does not guarantee success. This “advice” comes without any warranty. Try this at your own risk 🙂
• Do not try to replace Google as a main search engine (or a user’s homepage). This approach is probably doomed to fail. Instead, think creatively on how you can augment the Google experience.
• Dog-fooding is king. Lack of it (when building consumer products) is an alarming warning sound that should be shouted at every company meeting.
• An ideal Design Review is a meeting where you present the design, and everybody sits silently and nods (credits to Tal Kedar for this hard learned lesson).
• Sprint Retrospectives are great. They’re not always easy, and effectiveness sometimes slips in large groups, but they’re an essential component to a growing and learning organization.
• If three minutes pass and you still don’t understand what you’re doing at a meeting, find out. If you don’t find an answer that satisfies you, leave.
• Meetings should have an owner, who should come with a prepared agenda.
• Ownership is great. I encourage you to be a feature owner, domain owner, version owner, team owner. (Thanks Delver and Moti Karmona for pushing this idea to the limit)
• Feedback is vital. Don’t wait for it, create it.
  • It’s your responsibility as a professional to get feedback on your performance, and act on it. Are you making your boss happy? Are you making your employees happy? Are you making the share-holders happy? What can you do to improve?
  • It’s your responsibility as a product owner to get feedback on the product you’re building. Get this feedback fast, get it today, get it as often as possible. Developing features just because we think they’re cool is wrong. We are biased. We need to validate our assumptions and rinse out the false ones.
• Make sure you know the criteria for success. This applies to projects, positions, features.
• Expect that different people will have different (hidden, unaware) expectations. When in doubt, especially when working on large projects or with new people, make sure you are all synched in your expectations – if you’re not, it will hurt a lot more in the future.
• Communication is more important than code.
• Never start a data intensive project without planning for identification and fix of data corruptions. This will take longer than you expect, even if you take Hofstadter’s Law into account. Also, never get involved in a land war in Asia.
• Prefer to do full features, end to end, within the confines of one small team, instead of partitioning the design to different layers, implemented by different teams. It’s way too brittle.
• Human Resources really are useful (thanks Osnat Barak!)
• Management is hard. For me, it’s a tight balance between doing too much and doing too little. Thanks Shachar Zehavi for the chance to experience it.
• SSDs make developers happy and productive. So does freshly cut salad in the morning.
• The ability to effectively automate and remove little manual “pains” is precious.
• When a project’s internal milestones exceed their ETA by more than 30%, it’s a good time to wipe the plan clean and start again from scratch. People will tend to simply adjust the current ETAs, thus carrying over error.
• Hackathons/Code Dojos are fun! (and I haven’t even been to one yet)
• Think before you post/reply-to-all.
• You are responsible for your career. Nobody will build it for you.

I’d like to take this chance again to thank everyone I worked with at Delver. I learned from you all, and hope you also learned something from me as well. Till we meet again.