Week 5: 25/9 - 1/10
Well, the semester is picking up faster than I saw it coming... With homework, midterms, projects, and a continuous barrage of reading, and was has come to be my heaviest interview seasons so far, it seems like this week won't end anytime soon. To that end, let's get this week out of the way as quickly as possible. Here's my weekly story!
What did you do this past week?
I spent this past week doing interviews, finishing homework, and, much like every week, playing catch-up. I started the week on Monday with a full day interview at RetailMeNot, here in downtown Austin. Overall the experience was great, I learned a lot about the company, got some really interesting questions, and got home extremely tired. However, if there's anything that I learned from that interview it was this: do not overcomplicate your solutions. I'll expand on this on my tip of the week.
After that, I spent the middle of the week trying to get ahead on all my homework. First, we finished and turned in our Software Engineering Project which you can take a look at in phonedb.info. I felt very satisfied with this project. The website ended up looking gorgeous (props to Simon Zeng for fiddling with Webpack and React to get it to work as well as it did). I also got ahead in my reading, turned in some homework, and tried to catch up so I could leave Thursday night for another interview, this time in Microsoft, all the way up in Redmond, WA.
Here I spent Friday morning and afternoon in what turned out to be a set of 6 exhausting interviews. They all varied greatly in difficulty. From what I was able to tell (and both what I've heard and what I've experienced in previous interviews there), the first interview was used to determine if I'm a good enough candidate to go through more than 3 interviews or not. They varied greatly, going from full coding interviews to a lunch interview which was just me talking to an engineer, and finally, a design interview where I talked to someone who I'm guessing is either a potential manager or the manager of a sister team. Either way, it was a great experience. I finally finished the day by driving to Vancouver, visiting a friend, going Kayaking, getting to know the city a bit more, and driving back to Seattle to catch my flight back. Naturally, this strange one-day trip added with the fact that my US visa says I'm studying here in Austin confused the hell out of the Canadian immigration officer, but after a few questions, I was on my way.
What's in your way?
My roadblocks right now, like most weeks, are all the studying I'm missing. In particular, I have fallen behind in my World Literature class. This past week I should have read Metamorphosis, by Franz Kafka. However, since it's an online class through UT Extension with flexible deadlines, it's very easy to fall behind, since hard deadlines are more pressing. I'll have to catch up on that this week.
What will you do next week?
This is the interesting part. I'll start off my Monday with a reading due, as well as a midterm in the evening. That'll be followed by a first-round online interview Tuesday morning with Facebook London (an offer I'm really hoping to get). That'll be followed by a lighter rest of the week. I also need to get started on my AI homework on adversarial search. Finally, I hope to get some time in between classes and homework to pick up my personal projects again.
What's my experience of the class?
Unfortunately, this week I've had much less to say about the class. Since I was out for interviews two out of three classes this week, I can only talk about Wednesday. The only day I went to class we talked about testing multiple implementations of a single function. Specifically, we were looking at a few implementations for reduce(). The advantage of this is that we were able to look at this from the perspective of iterators. We wanted to ensure these functions all worked with any iterable. In other words, the only guarantee we had was that we could call iter() on the object. The way this is set up (such that you call a function iter() that takes in as a parameter the iterable, instead of having iter() be a method of the object) reminds me a lot of the design philosophy of the C++ STL. In both cases, we have classes that provide unrelated functions, and to define common interfaces all you do is define functions that make use of common naming conventions and change depending on the type to get the information they need. In Python, this works thanks to the interpreter. In C++, this works thanks to the templating system and tricks such as type erasure. Anyways, I found this interesting and very enlightening.
What's my pick-of-the-week or tip-of-the-week?
My tip of the week is something I learned from one of my interviews: Do not overcomplicate your solutions. Let me explain. There was this question they asked me in my RetailMeNot interview about an algorithm that placed objects in a listing with simple constraints such as "this item has to appear at or above spot 5", or "this item must show up at spot 3". The question was whether, given the set of constraints, it was possible to put down all items. Since all the constraints were only of those two types (fixed position, and above a given position).
There's an extremely simple solution to this: you first eliminate all positions for which you have a fixed position constraint and then fill out all other constraints in order (i.e. from most constraining to least constraining). The instant you can't place an item you're assured to have no solutions. However, instead of doing this, the problem formulation made me think of Constrained Satisfaction Problems (CSP's, which we had just gone over in AI). The interesting thing is this problem is a classic CSP, you can't get a more textbook formulation. However, if you solve it using the first solution can be solved in linear time. CSP's however, will run with a worst-case exponential runtime, because they don't take advantage of the fact that ordering does not matter. The point I'm trying to make is, sometimes the solution that comes to mind quickly and seems to solve the problem perfectly is not always the best solution. Try to exploit any information you have on the formulation to get a better solution until you can't find anything to take advantage of.