Rent the Runway is building the first online rental platform for retail goods. We're a disruptive e-commerce business that believes democratizing luxury products in the US is just the first step of a broader vision to drive aspirational experiences for tens of millions of users across the globe. We're more than "Netflix for dresses"—we're Cinderella Experience as a Service. Find out more about the challenging product-oriented problems we face across the boundaries of e-commerce, mobile, analytics and shipping/fulfillment here: http://blog.tech.renttherunway.com/

We are hiring front-end, back-end, DevOps, and mobile (iOS) engineers. Our stack:

* Service-oriented architecture with Java 7 (soon to be 8!) and DropWizard: Modern Java is a thing and we've got the proof!

* Ruby and Sinatra for lightweight, scalable web applications.

* JavaScript and Backbone for a front end that's becoming faster and more awesome to work on every day.

Job postings: http://www.renttherunway.com/careers

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

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.

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.

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...

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.

It's true that the ideas in the book transcend programming languages, and that the first 3 chapters could probably could be covered in JavaScript with little modification, if a little clumsily. But rewriting the 4th and 5th to include sections on parsing JavaScript would be quite challenging, and furthermore JavaScript does not have as simple semantics as Scheme, so there would be a loss of a great deal of elegance and beauty. The metacircular Scheme interpreter can run itself, which would be harder to do in JavaScript since its core is more rich and Scheme's core: objects, methods and so on complicate it quite a bit.

When we started spending 50, 60 hours a week at work. Even at 40 hours a week, it's exhausting to try to find any real time to devote to hobbies and "extracurricular" learning outside of work. If you feel like you're stagnating, feeling like you're wasting those 40 hours of life every week, why stay, just because "work is a financial transaction" ?

http://stackoverflow.com/questions/168254/can-you-write-gpl-...

It would be nice if someone from the Clojure team would add a FAQ page or something about the license to clojure.org as it pertains to users of the language... Since this seems to come up a lot.