spacemanaki

Rent the Runway is building the first online rental platform for retail goods. We are a disruptive e-commerce business that believes that democratizing luxury products in the US is just the first step of a broader vision of helping drive better aspirational experiences for tens of millions of users across the globe.

Our engineering team works on challenging product-oriented problems across the boundaries of e-commerce, mobile, analytics and shipping/fulfillment, and the backbone of our business is served by our custom logistics management system which is core to our capacity to deliver the right product to the right user at the right time. We utilize data, engineering and algorithms to create a personalized website and an adaptive supply chain to fulfill our commitment to an amazing customer experience.

Engineers at Rent the Runway focus on solving business problems first, and receive the satisfaction that they have true impact on the success of the company. Many of our engineers are entrepreneurs themselves, and we strongly encourage a collaborative, product-driven culture across our organization. We have a very diverse team and welcome those with supernerd CS degrees as well as those with non-traditional backgrounds.

http://www.renttherunway.com/careers

Comment · 12 years ago

Short answer: I don't think LYAH would be entirely sufficient background, and I think familiarity with imperative equivalents is a prerequisite, but along with some other background.

Long version: I stumbled a bit when trying to read this book, because I'm not super comfortable with the formal techniques for analyzing algorithms. I'm not talking about the kind of fluffy-tech-company-interview-"knows what big Oh is and can estimate it roughly on a whiteboard" ability but actually something much more concrete and formal, the kind taught in an undergrad algorithms class or in CLRS. I've taken those classes, I have CLRS on my shelf and have read some of it, but it's been a long time and it's not at my fingertips. There are exercises in the book ("prove that this data structure has this amortized performance", "prove that it does if you change this one thing", etc...) that challenged me quite a bit, and I ended up putting it down after a while thinking I would revisit it after refreshing my fundamentals.

The ML code is easy enough to follow if you know Haskell, but since the point is often to understand the subtlety of the performance characteristics of the data structures and algorithms, just reading and playing with the code wasn't enough for me. After all you can trivially implement functional data structures naively just by copying everything on every operation.

Frankly, Rich Hickey's videos on Clojure's data structures have done a lot more for me in terms of understanding how functional data structures work, even though they are much less formal in presentation. To be clear: I think Okasaki's book is probably a very good book and an important work, but am not so sure it is crucial for the working functional programmer to internalize all the mathematical details.

Anyway, YMMV. Check out his thesis and see what you think before buying it.

Comment · 13 years ago

A researcher in programming languages once told me that when she encounters the "HTML isn't a programming language" meme she always thinks: Agda and Coq aren't Turing complete, are they also not programming languages?

The point being, I think, that drawing this bright line at Turing completeness doesn't hold up when you give it any thought, and so it's not very useful. Aside from that, you've utterly missed the point of the OP.

Comment · 13 years ago

Please feel free to submit things that you think are more suitable for Hacker News.

Comment · 13 years ago

I have no idea what you're working on, but I spent a few weeks this summer writing parsers and trying to figure out how to tackle the ugliness that seems to be inherent in hand-written recursive descent parsers. While I learned a lot, I am not an expert by a long shot. However I did find an interesting technique that is not well covered elsewhere.

I came across this* article, which uses JavaScript as the implementation language, and found it very interesting, in large part because this approach (Top down operator precedence) sort of pulls the precedence hierarchy out of the call graph of a recursive descent parser and into a table, but also because it's an approach that OOP (and JavaScript in particular) is well suited to. I've used it (in combination with traditional recursive descent) in a functional setting (Standard ML) as well, and would use it again, especially for parsing infix expressions (arithmetic expressions, type annotation expressions).

This is a bit of a tangent, but I thought you might be interested given the intersection of parsing and JavaScript. I've been meaning to write this up in a short blog post...

* http://javascript.crockford.com/tdop/tdop.html There's another article on this using Java as the implementation language: http://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-e...

Comment · 13 years ago

The purpose of a question like this, and of the classic FizzBuzz question, is to be a lightweight test of whether a candidate can actually write code or not. That's all. It provides a negative signal if they fall completely to get anywhere close, and nothing more.

There are alternatives, you could ask them to explain a piece of code they wrote on their own before the interview, any piece of code would do. I suppose that could be gamed which is why most companies opt for FizzBuzz.

Personally, once I started thinking about these kinds of questions like this, I had less issue with them. Interviewing people who failed to write FizzBuzz opened my eyes too.

Comment · 13 years ago

It's not about macros, it's about homoiconicity. I encourage you to read chapters 4 and 5 and think about how sweet.js would help you port those chapters to JS.