tt

I was fortunate to be a student of Dr. Bose many years ago. No other professor gave unlimited time on exams, plus free Toscanini's ice cream to boot!

Beyond those small perks, his stories working with Norbert Wiener and his inspirations have completely transformed and shaped my personality and how I solve problems. Above all, the highest integrity one would have with his/her work, has been my #1 beacon thanks to Dr. Bose. I will always cherish that end-of-term field trip at his corporate headquarters where I witnessed amazing demos (including the active automobile suspensions), and heard even more stories that made me believe that anything is possible when you put your mind and heart into it.

Shameless plug for my own startup: for any San Francisco based company, Munchery is offering $50 off for any lunch or dinner order over $200.

We have multiple professional chefs who serve the entire San Francisco, cooking only sustainable, locally grown ingredients. Please ping me if you want to chat first.

Yes. We like hip chefs who can cook great food and who happen to run restaurants. Notice how you wrote that Little Delhi is your favorite Indian restaurant for delivery! :)

Edit: chefs create custom meal menus on Munchery.

We are vetting each chef profile, and applying Apple's infamous closed-door approach in an attempt to raise the bar on quality. There will be other features coming up that would give quality chefs much higher visibility than others.

I didn't feel too bummed about the reject. I feel like we didn't get in because: a) we are not first to market (it was immediately pointed out that there are many like us as soon as we sat down), and b) we are more of a service-oriented company instead of a product company. There are always exceptions, but investors typically want to fund product companies.

Because there are similar companies in this space, we need some unique insight in order to stand out (and our explanation on how we plan to give complete flexibility, or "leave it to the chef," apparently weren't convincing).

It's amazing how we picked ourselves up that very same night, had great discussions, revised our approach based on great feedback from other YC founders we met earlier in the day, and are moving forward. Thank you for all your support!

The problem HN is facing is a human-interaction problem of which hiding or showing points on comments won't solve. Sooner or later, problems with user experience will come about one way or the other.

I saw some other post about the Whirlpool Moderation forum (http://whirlpool.net.au/wiki/wp_modfaq) and thought the transparent moderation policy they have is pretty amazing. PG et al should at least research it and consider implementing something similar.

It doesn't matter very much how awesome your device is. You need at least a second person who would also get the alert as a backup (assuming this is a critical system that you really care about, otherwise you wouldn't want to be on-call for it in the first place).

As the primary responder, your responsibility is to acknowledge any alert within a minute or so. Otherwise, the backup person would have to jump in.

To ensure "accountability," you may have a manager who would be a third backup and can escalate up from there.

In my previous "day" job, I probably interviewed more than 100 candidates and hired about 15-20. Here's what worked for me:

1. Phone screen (~45-60 mins). I'd spent ~15 mins going over what the company does, what the work environment is like, the team structure, the personalities, the technologies, etc... I'd try to "sell" our opportunity to jazz up the candidate and get them at least curious and hopefully very interested. I'd weave in a little of why-are-you-changing-job, what-was-your-experience-like, or what-would-you-prefer, and then ultimately we spent the majority of time on a recent project that he/she can talk about in depth. I pushed on a few related technical aspects to those projects to see if the candidate could clearly explain himself/herself technically.

2. First round (1.5-2 hrs). If I liked the candidate's potential after the phone screen, I'd invite him/her to our office to meet me and another engineer. We'd go into more depth about their recent project(s), and then go through a design/code exercise for a web application (the company builds web apps). The exercise was very open-ended (there's really no one correct way to do it). The design/coding choice depended on many factors, and we helped steer the conversations so the candidate could talk about those factors and what he/she would do to handle each of them (including when not to handle certain situations).

Along the way, we also probed into how he/she would work with other team members, how/whether to "challenge" another colleague, what/if any development process he/she would follow.

There was no trickery, no reversing a string, no linked lists. But I might ask how one would deal with concurrency conditions (two users trying to claim a single resource), how to scale with traffic, etc...

The candidate was encouraged to ask questions throughout the interview. It was a two-way street after all.

3. Second round (another 1.5-2 hrs). If first round went well, I'd invite the candidate back to meet a few other employees (e.g., another engineer, a Product Manager, a designer for example). I asked these other employees to ask anything they'd like, but at the end be able to tell me if this candidate would a) be smart, b) get things done, and c) have right cultural fit. If anyone had strong objection from this round, it almost always resulted in no-hire.

Equally important to hiring well is to let employees go quickly if they don't fit. That's a separate subject worth its own post.

I was worried for a bit because I thought there's new competition for our Munchery (http://gomunchery.com), which is much more like Airbnb for food. :)

Quality is one of the top priorities in our mind as we roll out beta. That's why we select professional chefs to start with. Some of the chefs want to specify a max number of subscriber, so we know they also want to ensure high quality and not have to prepare too many meals.

Our chefs and restaurants vary a bit when it comes to pricing. With this omakase style, it's true they can get in-season ingredients and that helps lower the cost (and also increase the quality of the food). But if they are a all-or-mostly-organic meal provider, it's still hard to get the price really low.

They put in great engineering effort to ensure high availability despite random instance failures. I really like their Chaos Monkey.

See: http://techblog.netflix.com/2010/12/5-lessons-weve-learned-u...

Agreed. It's on the todo list. :)

We currently have one chef who delivers to Sunnyvale: https://gomunchery.com/chefs/evolution-catering

Thanks for the props as to why this is a good idea. But I'm actually very interested to hear why you think Munchery WILL NOT work. Why it will suck? If you have signed up thus far, and you live/work on SF, what prevents you from placing a subscription order?

I'm eager to iterate on our approach based on everyone's feedback!

Each chef does his/her own delivery at the moment. The availability schedule sets the day/time that you would likely get your meals.

We definitely imagine offering a delivery service for chefs in the future!

I've been on HN for years, but hardly comment due to a busy day job. Three weeks ago, I decided to quit the day job and focus on Munchery full time. It's super exciting to say the least!

This is likely to be a political battle between the progressive members of the Board of Sup and what former Mayor Newsom had apparently set up with Twitter.

Newsom had always focused on developing and growing high tech companies in SF to increase jobs and revenue for the city. On the other hand, certain members of the Board strongly believe in taxing our way out of the deficit. As a startup founder in SF, it's sad that I may one day have to deal with this.

There's a saying in Vietnamese culture that goes along the line of "Compatible husband and wife can empty the Pacific." I live by that.

We are working on a startup that directly solves this problem of needing to eat healthy food, yet too busy to cook, and too tired to order or eat out.

See http://gomunchery.com

Back when I was an intern at IBM in upstate NY, I often drove between Boston and NY late at night. There was no cars in sight in the early hours of the night for certain parts of hwy 84 and 684. No cell phones back then either.

I periodically saw people whose cars had broken down on the side of the road, and stopped each and every time to offer help. One time, I drove a woman and her young son to a nearby gas station to make phone calls. Another time, I drove another couple to a nearby town.

It turned out that for one such time, I happened to help the daughter of a researcher who also worked in the same IBM research lab I was working at. The next morning, the father looked me up and took me out to coffee to thank me. That was sweet.

Nowadays, I no longer have to drive late at night, but I still look for the opportunity to help. It has always brought me peace to know that I can get someone out of a jam when needed.

I would pay $10 to $15 a meal.

A couple other things to consider:

1. Create a multi-column index that satisfies the query entirely on its own without the need to go to the table to read additional data. This technique solves a large percentage of slow query problems.

2. A bitmap index in Oracle kills concurrency. Do not use bitmap indexes for table with multiple concurrent transactions.

Also: not allowed to use Oracle's native date data type, and no foreign key constraints allowed!

> The idea of putting any logic in the database never did make much sense to me for these exact reasons.

I'm a big proponent of enforcing business rules right into the data model. Constraints such as not null, reference constraints, or even conditional unique constraints (yes, there's such a thing!) should be enabled wherever possible.

Just remember, your app will not be the final app that makes use of the data. Your app comes and goes, along with many other apps written by many others. But the data lives "forever."

Thanks! We'll definitely keep these in mind.

Indeed, no need to specify the radius. It would not consider a match if you have to go too far out of your way to pick up someone else.

Indeed this would be a challenge. If you have no predictability with time or even dates of travel, then http://www.ride4all.com wouldn't be very useful for you.

Also, if you have a short commute, say 5 miles or less, then you probably wouldn't bother.

But if your commute is 10-15+ miles, and as gas price increases (say to $6/gallon), would you reconsider?

I live in SF bay area, and I flinch whenever seeing tons of people in single-occupant cars stuck in traffic, day in and day out.

Regarding the response time, it's really out of our hands (and in Google AppEngine's hands really). Hopefully that will improve if indeed Google AE had issues at the time you clicked.

Regarding disclaimer, yeah, we thought about that. Indeed need to add that. Thanks David.

We are planning to introduce a "group code" feature, which allows people within your known social circle to use and find rides among each other. Would that work?

We are currently shying away from another facebook app, but maybe that's the way to go for this.

Depending on exactly what your non-profit does, but another thing you most likely would run into: most funders/donors, especially the up-and-coming, really want to know your non-profit's effectiveness before sending you any money.

Most non-profits have no resources to do this well and/or they simply don't think this way.

Here's my benevolent startup: http://www.goalshift.com .

We offer an online tool to help non-profits measure their client goal progress and correlating with the programs/activities they serve. Visual charts clearly show progress.

It's entirely free for small organizations or small programs.