Smart and Gets Things Done Are Not Enough

Once upon a time, hiring programmers began with making a list of things they needed to know. Actually, you can still see plenty of job descriptions today that read like a snooze-inspiring checklist.

Requirements: Bachelor’s Degree or Military experience — At least 12 years of experience with Enterprise application design and construction with an emphasis on web architectures — At least 7 years experience in SOA environments working with SOAP or at least 7 years of experience with RESTful web services- At least 7 years of -.NET (C#), ASP.NET- — At least 5 years of experience with UI Design — At least 5 years of experience with -HTML.

That is excerpted directly from an actual, live job posting. And it keeps droning on like that for several more paragraphs. Painful, no? Do you wonder how its authors decided that it should be 7 years of .net, but only 5 years of HTML? Should you really not apply if you have 7 years of HTML and 5 of .net? Do they really not want you if you are the author of a major open source library but don’t have a bachelor’s degree?

On the plus side, pretty much only big, ossified corporations think this way anymore, which means that they are missing out on smart, awesome people. Cue evil laugh and nefarious rubbing-together-of palms — this means lots more smart and awesome for the rest of us.

Way back in Y2K, when otherwise normal people were avoiding elevators and stockpiling canned chicken, Joel Spolsky wrote an incredibly influential article called The Guerrilla Guide to Interviewing. It is still well worth a read, but the biggest takeaway is: stop hiring for predefined skills. Instead, hire for two traits: Smart and Gets Things Done.

At ChefSteps, we take this advice seriously. You should hire smart people because they do smart things that make your products better. Smart developers write clean, concise, well-factored, reusable, tested, DRY, performant code. And you never have to give them the same feedback twice.

Smart is necessary but not sufficient. Your hires must also be people who get things done, because if they only sit around and theorize about smart things, you’ll never ship. And all that not-shipping is going to make you pretty darn stabby.

So where does experience come in? Great programmers pick up new stacks in short order. So it rarely makes sense to hire someone based on his or her familiarity with a particular language or tech stack. There are two exceptions to this rule. Actually, there is one full exception, and one half one.

First, the full exception: Sometimes, deep expertise just matters. Someone, for example, who has worked extensively on web-scale services — and wrestled with all of the SLAs and security issues they entail — just knows things on a visceral level. And that knowledge may well keep you from cutting yourself with very sharp objects. Sure, you can ask a great frontend developer to learn that stuff, but expect it will take them a year or more to be truly fluid at it. So when the stakes are high enough that stabby-ness is in play, go ahead and hire for expertise.

Onto the half exception. Let’s say you’ve got something absolutely urgent to do on a particular stack. Your iOS app is six weeks from shipping, and the critical new user onboarding experience isn’t done. Okay. This is not the time to bring in a phenomenal backend developer and get her up to speed on Swift. But if you find yourself with an immediate need, and don’t believe you will have an ongoing role for the person who can meet it, or know that hiring him means compromising your normal standards, you should use a contractor or agency to solve the problem. That solution has its own headaches, sure, but it’s better than forcing a lackluster hire on you and your team. Once the crisis is past, you probably should figure out how you got yourself in that mess in the first place.

So, Smart and Gets Things Done are great criteria for new hires. Let’s add a third: Not a Jerk. No matter how smart someone is, no matter how good his code or how fast he writes it, we’ve got no place for him on our team if he makes everyone else miserable. Frankly, I don’t care about the beer test or even the Sunday test. They can actually work actively against diversity and lead to a team of code bros. But if you find yourself interviewing the type of programmer who always has to be the smartest person in the room, or that gets his jollies from insulting coworkers, or — worst of all — shows himself to be ethically challenged, the door shouldn’t even have a chance to hit him on the way out.

The problem is: Smart, Gets Things Done, and Not a Jerk are table stakes. As competitive as the market is for engineers is these days, it is tempting to hire people who just hit those marks. But hire based on those criteria alone, and you may end up with a team of highly fungible, tremendously boring robots.

The context of your company or team matters a great deal. At ChefSteps, being part of a startup with a big vision means our hires need to gracefully embrace ambiguity and change. We are trying to reinvent the kitchen, not disrupt inventory management for janitorial supplies. If you expect to always have complete specs and perfect design docs before you build a feature, this isn’t the right place for you.

And you know what? I know myself as a manager and leader. If a developer is only productive when I hound her to keep her backlog organized and her bugs under control, and I can’t trust her to make important tradeoffs, we won’t work well together. My job is to help my team understand the overall context of what we are building as a company so our decisions are aligned. I do my best to make sure they have what they need to be successful, and shelter them from distraction. I find them awesome coworkers to execute with, and help them work through the inevitable human issues that pop up. I’m also super-excited to talk through technical issues, but I’m nowhere near smart enough or patient enough or in-enough-places-at-enough-times enough to coach anyone through her job on a daily basis. So to thrive here, engineers have to relish autonomy along with massive responsibility.

Beyond these fundamental requirements, every great engineer that I’ve worked with brings distinct additional strengths. Just to pick a few examples, they might:

  • Know every line of a multi-million line codebase and be able to diagnose a bug without even looking at any code.
  • Be unrelentingly optimistic and never give up on a goal, even if it takes years to come to fruition.
  • Crush any obstacle that comes between them and done. Before lunch.
  • Be a grizzled vet who has shipped so many things that they help the whole team make great tradeoffs…
  • … or be relatively new, but so motivated that if you take a chance on them, they will repay it 10x.
  • Bring a completely different perspective that changes how you think about a problem or a whole project.
  • Reduce your stress level because you know that anything that lands in their lap is 100% handled.
  • Make the team so fun that everyone can’t wait to get to work, or loves to hang out together outside of work.
  • Have a knack for isolating and eliminating the nastiest, most difficult to reproduce bugs.
  • Have the empathy and passion for education that makes them great at mentoring interns and less-experienced but promising newcomers.
  • Be so incredibly committed to your product that they will stretch in unexpected ways to make it a massive success.
  • Engage directly with users to turn them into evangelists and help the whole product team learn what they really need to build.
  • See the big picture of the architecture you are building and save the team years of wandering the right way down the wrong paths.
  • Be emotionally intelligent in a way that recognizes when colleagues need to talk about something difficult, or even initiate those conversations that would be easier to avoid.
  • Be passionate about growing the team and help you identify and interview terrific candidates.
  • Read all the blogs and be aware of the bleeding edge of tech. (Bonus points if they have enough taste and self control to know when to actually use the bleeding edge of tech).
  • Challenge you and call you out — very publicly if need be — when you are being a jackass.
  • Love to put on the headphones and knock out impossible features, impossibly fast.
  • Have a sensitivity to user interface that allows them to collaborate unusually effectively with designers.
  • Be a tool builder who will continually make your team more efficient.
  • Communicate effectively to other technical and non-technical teams.
  • Surprise you with futures and prototypes you’d have never thought of.

No candidate is going to bring all of these strengths to the table, but any great candidate will bring some of them. Ideally, your team will grow to include people with a diversity of them over time. To improve your odds, be sure to write job descriptions that communicate actual passion and the flavor of your company. Ask open-ended questions that invite candidates to show you their personality, follow-up about subjective skills in reference checks, and discuss them in your hiring decision meetings.

Now for the really subjective part. There is something else I look for in every hire, a proxy, of sorts, for that long list of soft skills: are the lights on in their eyes? There are plenty of candidates that I talk to that are … perfectly fine. They are solid programmers; they’ve shipped things; they are nice people. But certain people just have that spark, and when you see it, you know that you want to work with them because they are going to make your life and your team way better.

So, tell me, does all this jibe with your experience hiring engineers? Are there other things you look for in candidates? And how do you identify those subjective — but crucial — skills that will never show up on a checklist?

Michael Natkin is the CTO of ChefSteps. We are reinventing the kitchen. And hiring.

From Big-Tech to Startup By Way of the Kitchen

Developers often get pigeonholed, not just into technologies but into the types of companies they work for. If you start out working on financial back-ends for banks or join Microsoft fresh out of college, it is all too easy look up from your cubicle a decade later and realize that you haven’t seen the world. I’ve been fortunate enough to work in several radically interesting and different environments, from special effects studios, to traditional software companies, to professional kitchens. At each stop I’ve learned how to be a better engineer, how to contribute to different types of teams, and, maybe most importantly, about myself. My hope is that by describing my own trajectory and experiences, I can help you figure out whether you should consider giving up your comfortable career at a big company for something as mad as a startup.

I started programming back in the 1970s at the age of 12. My dad brought home a model-33 teletype that was connected to the Louisville Board of Education’s Honeywell mainframe, where I could write code in BASIC. Yeah, it was a freaking printer, with a 110-baud modem, and a paper-tape reader. And I was in love. Since the statute of limitations has long since expired, I don’t mind telling you it wasn’t long before I was hacking into computers all over the country — for the pure love of the puzzle. Next came DecSystem-10 assembly programming, and over the next few years I would hang out at Radio Shack stores and the University of Louisville Apple labs — anything to get my hands on computer time. By the time I was 16, my friend Dave and I had a contract to develop accounting software (with a surprisingly sweet user interface) that ended up being used for decades.

ASR-33_2

When I went off to Brown, I hoped that the years of coding under my belt would give me a leg up in the Computer Science department, and it did. I joined Andy Van Dam’s computer graphics group as a freshman, and through that, plus a short stint at UC Berkeley, I made friends that led to 20 years of awesome jobs. If I could tell a young developer one thing, it is that pouring your heart into your work and building great relationships in your career will always open doors for you. I don’t mean that you need to be calculating in how you make friends, simply that if you devote yourself to be a first-rate programmer and a reliable teammate, your friends will want to work with you again wherever they land.

My first stop after college was Industrial Light & Magic. I showed up for the interview in a suit, but they hired me anyhow. My friend Eric was the first full-time programmer there and I was the second; prior to that, they had technical directors writing code, which was a scary thing indeed. On my first day at ILM, I got to be on set when the practical effects team blew up the giant warehouse model for Backdraft. During my stay, I worked on Terminator 2 and Jurassic Park, and loved collaborating with artists and directors. It was high pressure fun: “We need a way to make the T-1000 morph up out of the floor, but if you can’t figure it out by tomorrow morning, I guess we’ll just animate it by hand”.

Moving on from ILM to Silicon Graphics was a big decision, but in spite of the excitement of the movie business, I was tired of 80-hour workweeks and ready to move on. SGI machines were the workhorses of computer graphics in those days, and once again, I had close friends working there. I joined a team building a set-top box with a ridiculous 3D interface. I had just moved to Milwaukee so I was doing an early experiment in telecommuting and thought it was pretty glamorous to be in my mid 20’s and taking fancy business trips all the time — including the first of several trips to Tokyo because our initial deployment was with NTT. When the set-top box went down in flames, I joined the VRML/CosmoWorlds team that made an early, valiant, and hopeless attempt to bring a 3D graphics standard to the web.

It turns out I had joined SGI when both the stock price and hubris were at an all time high. When competitors like NVidia started making graphics boards that were an order of magnitude cheaper, we thought they were toys. While SGI was busy sponsoring Hollywood premiers and its executives were holding company meetings with increasingly dubious levels of fanfare, those competitors ate our lunch and hired away most of the best engineers. I don’t regret my years there at all, but I learned a few important lessons: (1) having the best technology doesn’t mean you will win — and your technology probably isn’t as far ahead as you think it is (2) if what the execs are saying sounds like BS, it probably is and (3) don’t be the one left behind to turn the lights out.

Adobe was an entirely different situation. I spent 12 years there as one of the lead engineers (and, briefly, engineering manager) on the After Effects team. After Effects started out as its own small company (CoSA), founded by a group of engineers that I knew from Brown, and then it was acquired by Aldus and in turn snapped up by Adobe. In fact, funny story, when they first started building After Effects and I was at ILM, the team came by to show it to me and my first reaction was “this will never work.” I couldn’t have been more wrong. It grew into a professional tool that hundreds of thousands of people around the world love and use to make their living.

My time at Adobe reflected pretty much everything that could be great about working for a big company. I doubt that 1% of engineers have a situation that good. Especially in the early years, we had the best of both worlds. The After Effects team was pretty much autonomous. We knew our customers and built what they needed. We had ownership of our product and control of our destiny. We were a tightly knit bunch that spent lots of time with each other (and later, each other’s families) outside of work. My teammates were brilliant, and we knew each other so well that I think we could communicate whole designs with the raise of an eyebrow. At the same time, the larger company added tons of value. We had job security and stability, great benefits, and work-life balance. And because Adobe makes Photoshop, Illustrator, and Premiere, we got to build best-of-breed integration with those products, using the same core libraries they were built on.

And yet….

There were still things that gnawed at me. Big companies can’t help it. There are boring corporate meetings, and increasingly irritating product requirements that come down from on high. Executive whims and people scrambling to figure out which way the wind is blowing and align with it. Corporate buildings are still corporate buildings even when they have really well-stocked candy jars. HR processes so tedious you can actually feel your hair turning gray. Reorgs that left you needing a frequently revised cheat sheet to remember the path from you to the CEO.

When you are building desktop, shrink-wrap software, builds and QA and deployment is generally a pretty painful process. We got used to shipping every year or 18 months; even with agile processes there would still be months of excruciating bug fixing at the end of each cycle. And worse, build times could often be 10 or 20 minutes. It is pretty hard to get in the flow as a programmer when you are interrupted for that long on a regular basis.

And then there is innovation. Adding a cool new feature to After Effects? No problem at all, I could make that call myself, or over lunch with the team. But starting a new product? You’d better have some serious fortitude because you’ll need to go through N levels of executive review, and you’ll need to prove that it could generate tens or hundreds of millions of dollars in revenue. Because anything less than that isn’t going to move the needle. Worse, you’ll need to keep proving the same thing every quarter, because incubating a team and a product takes a long time and corporate memory is short. All big companies talk a great game about innovation, but it mostly goes against their inherently conservative DNA.

Let me be clear, this has nothing to do with Adobe. The same is true at Amazon or Apple or Microsoft or Google (or Boeing or Ford or Bank of America). But there came a point when I knew it was no longer the best fit for me.

I had always had a great love for the creativity and physicality and human connection of cooking, but it never seemed like the right time to take the professional leap from the keyboard to the kitchen. So in 2007 I started a blog as an outlet for that passion. While I was still at Adobe, I took time off to stage at a few restaurants, and the blog led to an opportunity to write a cookbook, which became a finalist for a James Beard award.

When the book was published, I took that as an impetus to leave Adobe, do a book tour, and begin planning my own restaurant. I was excited (and, obviously, terrified) by the unknown in front of me. And still, leaving was painful, primarily because I knew I would no longer see some of my closest friends on a daily basis.

And then a funny thing happened on the way to that hypothetical restaurant.

It was November 2012, and I was in hot pursuit of the perfect space to set up my $35-per-plate, lunch-only modern vegetarian concept. Sure, the numbers weren’t exactly penciling out but I was determined to make it work. In my morning spin through the web, I saw a note about a startup called ChefSteps that was going to teach the world about cooking sous vide, with alumni of the Modernist Cuisine team as founders. I had read Modernist Cuisine cover-to-cover and was fond of filling my kitchen with the comforting smells of locust bean gum and sodium hexametaphosphate, so naturally I reached out. My first pitch was “Hey, I’m a food blogger, want me to come write a piece about you?” Answer, in translation, “Meh.” My second pitch was “Oh, by the way, I also write code.” Answer, “Can you be here tomorrow at 10?” No translation needed.

The courtship was short and intense. The first week I was hanging out, I built a feature that their contract development house had claimed was more or less impossible. The next week we fired the contract developers and I signed on as CTO.

This was a pretty big gamble on everyone’s part. My knowledge of web programming was indistinguishable from zero. I spent a few days with the contract devs before we let them go, and they would say things like “to configure SSO we need to add a route and a controller method and then disable CSRF and return the right headers, but I think there is a gem for that.” It sounded to me like the teacher in Charlie Brown cartoons: “Wahhh wah. Wah wahh dumbledore wahh wah.”

Still, programming is programming. Well-factored code is well-factored code. A function call is a function call, whether it executes locally or hits a web API. Any solid developer could make the switch. It took a few months before I felt mostly up to speed, but I’ve come to love modern web programming. For one thing, there are no build times. You can generally see the results of your work as fast as you can reload a web page. Since I’m incredibly impatient, that is only slightly too slow for me. Automated testing is much easier to achieve than it ever was in C++ land. And because web development is so closely associated with open source, there is a worldwide community solving problems together. I was so accustomed to needing a mental map of a proprietary million-line code base and spending hours in a debugger; it is an amazing feeling to jump on StackOverflow and be able to find a solution in minutes.

There is a part of me that feels a twinge of loss when I picture my restaurant; it is a romantic vision, expressing that creativity daily and feeding a small group of passionate customers. But, I know all too well the reality of restaurants. Ninety percent perspiration is a lowball figure. I traded that in for a situation where I can work with some of the best, most knowledgeable chefs in the world.

At ChefSteps we believe in working with “T-shaped” people. For me, the depth of the T is coding and working with a software team, and the breadth is food and writing and experience growing my own website and book. Although I usually don’t do much more than kibbitz on the actual food here, or try an occasional goofy experiment (iceberg lettuce cocktail, anyone?), my culinary experience is a huge advantage in building applications that work for both the team here and for our users.

Beyond the mechanics of code, working at a startup brings a whole different set of joys and challenges than I ever experienced in the corporate world. The entire risk/reward equation is completely different. At a big company, you mostly work on low risk, incremental improvements to grow or maintain your market and keep your customers happy. At a startup, if you aren’t betting the company, you probably aren’t taking enough risk. Because what you’ve built so far simply isn’t valuable enough to be worth protecting. It requires a very different mindset. In the early days that can cause a scary degree of pivoting, but over time you begin to converge and develop momentum as a team towards big, hairy, valuable goals.

You quickly realize that every decision you make has tremendous impact. There is no room for red tape, no room for laying back and saying “not my problem.” You are all in this together. You get mad at each other. You make up. You push each other, and find strengths you didn’t know you had. You have each other’s backs. And sometimes you all stop what you are doing and move all the furniture, because there isn’t a facilities department to call.

Working at a startup in Seattle has put me in touch with startup culture in general though, and I’ve realized it isn’t homogenous. There is a Silicon Valley-style startup culture (not limited to California) that is almost entirely focused on the “quick kill” mentality. They want to figure out something that no one else has done, market it virally, and make a quick exit. That mindset lends itself to using people. I’ve seen companies that have hired 50 programmers almost as if they hope that one of them will accidentally type Shakespeare, rather than trying to nucleate a team of a few very high-functioning engineers. The hope is those 50 engineers will get them through to the next round of VC and they can lay off the bad ones. This kind of startup isn’t built around any kind of core love for a particular product, just the thrill of money and/or power. I can’t imagine anything more boring.

At ChefSteps, we are trying to do something very different. You can see it in where we come from. Just as I came from After Effects, which has been building value since 1993, our founders, Chris and Grant, last worked on Modernist Cuisine where a team of 30+ people spent five years writing one cookbook. And you can see it in how we are funded. Gabe Newell didn’t build Valve to be a one-hit wonder, and he didn’t bet on our team to make a quick profit. ChefSteps isn’t just a business plan or a loose dream of failing fast and iterating our way to an acqui-hire; it is a philosophical experiment in allowing a group of smart, motivated people to self-organize and solve giant problems. We aren’t just a group of programmers, we are a team of cooks, writers, videographers, musicians, business people, designers, scientists, mathematicians, mechanical and electrical engineers, and maybe a stray aerodynamicist, all focused on helping every cook to cook smarter. This isn’t going to be achieved in one year or with one product, but what truly worthwhile goal is?

Meet ChefSteps’ new Ingredient Wiki – And Enter to Win A Free Class

The web is full of information about ingredients. All you have to do is search for smoked paprika or maitake mushrooms and you’ll find sheafs of information. So why did we decide to launch our own ingredient wiki at ChefSteps?

Well, as enthusiastic cooks we run into the same problems over and over again: the information we find on the web isn’t necessarily food-centric, it isn’t well structured, it is too commercial, and it isn’t always reliable. Even Wikipedia, as great as it is, often bogs down into botanical or pharmaceutical details that don’t help much in the kitchen.

Ingredient Wiki Gallery

Our ingredient wiki is designed by cooks, for cooks. Each entry connects to recipes that use it, and to other ingredients that are frequently used with it. Text sections describe relevant culinary information, such as alternative names, purchasing tips, and seasonality.

The best part? This is an opportunity for you to contribute your time, knowledge or skills. You don’t have to be an expert to help! Of course we are delighted if you are an asparagus-savant and want to write a complete article about it. But we are just as happy if you will take a moment to:

  • add just a sentence or two,
  • copyedit what someone else has written,
  • add a photograph,
  • add a weight to the Volume Conversion section,
  • or simply tag the article as “vegetable” and “Spring”

If everyone contributes just a little, this could quickly become a comprehensive, dynamic ingredient resource that benefits cooks around the world.

To get involved, simply sign in (or sign up) with your free ChefSteps account, and visit the ingredient gallery. You can browse, search the gallery by name, or sort it to find recently added or edited ingredients that you might want to work on.  You can also click through from the ingredient list in any recipe on the site. Don’t see the ingredient you want to write about? Just click on “Add Ingredient” at the top of the gallery and get to work!

Here are some examples of articles that already have quite a bit of content, so you can see what the possibilities are: chickpeas, xanthan gum, garlic.

If you have suggestions about how we can make our new tool better, we’d love to hear from you at info@chefsteps.com.

Oh, and about that contest! Anyone who edits any ingredient entry between now and January 15th, 2014 (11:59 PM, Pacific time) is automatically entered to win. We’ll pull names out of a hat and give away free enrollment into a paid ChefSteps class to three lucky winners. (Winners can choose from our French Macarons or Whipping Siphons classes, or wait for the next one we publish.) The contest is over now; congratulations to our winners Marco, Marc, and Diana and thanks to everyone who contributed. Keep those ingredient wiki entries coming!

A Word to the Geeks – What We Are Building at ChefSteps

Looking at ChefSteps today, you will see a gallery of beautiful recipes, our first several courses, and a thriving community of members eager to cook better than they ever have before. We are proud of what has come thus far, but we also want to share what we hope to build in the future: a radical change in the way recipes are documented, shared, and evolved.

Superficially, presenting recipes looks like a simple problem. Cookbook authors have been doing it for decades. You have a list of ingredients and equipment, and a series of steps you apply, and dinner is made.

As soon as you scratch the surface though, there are all sorts of interesting problems and opportunities to make recipes better, both for end users and for recipe writers (which ultimately could be anyone who cooks).

Take ingredients, for example. If you look at a recipe and see an unfamiliar ingredient—maybe smoked paprika—you’d like to be able to click and quickly research it. You might want to know where you can purchase it, of course, but also where it comes from, how it is traditionally made, what substitutions to consider, what it pairs well with, whether it is gluten free, etc.

But it isn’t as simple as linking the ingredient name to a page of text. Is an apple an ingredient? A green apple? A Green Winter Pippin? What if it is peeled, cored, and diced? Dehydrated? The answers matter, and they aren’t simple: if we consider them all to be different ingredients, we’ll miss out on opportunities to share information that is consistent across the various forms. If we consider them to all be the same, you might end up making apple pie from a variety that doesn’t bake well.

Can we be both precise and tell you that you need 500 grams of diced apple, but also help you out for shopping and let you know that that is about 3 apples? Can we scale that quantity up or down in a sensible way depending on the overall context of the recipe?

It is going to take both a sophisticated model and the contributions of a passionate community to fully capture all of this complexity.

If you take a look at other websites that have tried to structure recipes, they’ve hit the same issues and basically punted into just marking up text. The semantics aren’t really captured at any deep level. There are sites that are trying to solve the ingredient problem with natural language processing, because they want to be able to sell you the ingredients for an existing recipe, but as you can imagine that falls apart pretty quickly, presenting inaccurate or incomplete information.

And what about recipe steps? Everyone writes them over and over as plain text, but they tend to have a repetitive formal structure. When professional chefs share recipes, it takes just a few words because of a shared understanding of what it means to sear or hydrate or emulsify. Can we deliver that kind of concision to home cooks and provide them with deeper explanations and videos just-in-time when they are lost? Can we help them troubleshoot when it has all gone wrong?

On the authoring side, I’ve written hundreds of recipes, and yet when a professional recipe editor works on them, they always get better. You can imagine how bad recipes are when they are written by folks who have the gift in the kitchen but not at the keyboard. Can we make it much easier for cooks to express their formulae in a way that other people can replicate?

Recipes are hard to optimize because ingredients and techniques interact, so you can’t just vary one thing while holding everything else constant – in many cases it is a full combinatorial problem, with multiple local maxima. What is the equivalent of github for recipes? Can we create that same sort of environment where recipes can be shared, co-authored, forked and improved? Can we make it possible for groups to self-organize around the development of the ultimate barbecue sauce or baguette?

We’ve made some baby steps on all of these problems – our existing recipe display lets you scale and change units on recipes in a way that, while simple, hasn’t really been done before. Users can enter their own recipes in an intuitive, structured WYSIWYG format with as much or little detail as they like, and they can “fork” an existing recipe to create their own variations. But as you can see, this just barely scratches the surface of what we plan to build. There are years worth of good problems here.

And by the way, if you are reading this and thinking “boy, I’d love to be a part of that development team,” and you’ve got the chops to back that up, we’d love to hear from you at jobs@chefsteps.com.

ChefSteps Is Hiring: Software Developer

ChefSteps is an incredible place to work. I don’t believe there is any place else in the world that brings together this level of culinary, food science, videography, design and technological talent under one roof. We are a small, entrepreneurial startup where the right person has the opportunity to shape the direction of the company, and ultimately, the future of food on the Internet.

If you are the person we are looking for, you are a true software unicorn, the rare creature that is able to design and implement large projects in a self-directed fashion, assimilating whatever technologies are most appropriate, and striking the right balance between writing beautiful code and shipping it rapidly and iteratively. When pointed at a target, you eliminate obstacles  and just make it happen – usually in a way that is more awesome than originally envisioned.

If you have the track record to show that you can learn new languages and libraries fast, you don’t need to have used everything we are built on now. But it is certainly a positive if you know some or all of Ruby on Rails, HAML, CoffeeScript, JQuery, Angular.js and Heroku. It also helps if you are passionate about food.

Our team is based in Seattle, in 4000 square feet of amazingly cool space below historic Pike Place Market. We are open to a remote developer as long as you can spend an initial chunk of time on site and visit here frequently.

Want to apply? Please drop a note to jobs@chefsteps.com and include the following:

  • Links to places on the web where we can see awesomeness that you’ve built (including any github repos you’ve made major contributions to)
  • What you’d change about the current chefsteps.com
  • If you have a current resume, let’s see it

Want more info?

ChefSteps ISO World-Class Designer

ChefSteps has come a long way in the past few months. Our sous vide course is closing in on the half-way mark, the forums are a hive of community activity, and we’ve created our first food product. Our team is continuing to push the limits of what’s possible in the kitchen, and figuring out new ways to share our fascination with the how’s and why’s of cooking using our skills as writers, photographers, musicians, and filmmakers. We’ve hired our second software engineer and continue to build out the site and the course; look for some great new features soon.

Taking a step back from all of that activity, we are headed toward a larger vision. We want to bring culinary education into the modern era, and use science to help you make your cooking more delicious and enjoyable than ever before.

We are ready to add another piece to this puzzle: a great designer that can help us make the website look and function in a way that does justice to that larger mission. Everyone here has tremendous respect for the work of designers. We know that a great designer doesn’t just make pretty pictures. They make or break the entire experience that the community has with your content. A great design enhances great information, makes it easy to find what you want, and directs you to things you didn’t yet know you wanted, all while being almost invisible.

Could you be the designer we are looking for? Or do you know someone who is? Here’s how to tell:

  • The pace of work at ChefSteps is breakneck. You are comfortable with that pace, with surfing uncertainty and refining on the fly. We believe in iteration, not immaculate conception.
  • You are a switchblade. You are equally capable of contemplating the information design of a meal timeline in a PDF ebook, designing a logo from scratch, figuring out what variations of a landing page we should test, or creating a new template for our weekly emails.
  • You know how to strike a balance between beauty and functionality. Beautiful pixels are important. Beautiful pixels that serve their intended purpose are golden. (Well, actually a lot of times they are #ffffff.)
  • You are both strategic and tactical. You’ll help hold the big picture of what we are trying to accomplish over the next several years, but will also be very happy to get into the nitty-gritty of what needs to get done right now.
  • You have a modern, minimalist aesthetic that will work well with our photos and video.
  • Working with a world-class interdisciplinary team in startup mode isn’t intimidating, it is your idea of a great time.

Bonus points:

  • If you are able to do some HTML and CSS yourself, in addition to handing over pictures to implement, that’s a great thing.
  • If you have a love of food and cooking, it couldn’t hurt.
  • If you live in Seattle, we’d love to have you on-site, but we’ll consider remote work if you can spend some time with us getting started.

Sound like a dream job to you? Got the skills? We’d like to talk with you. To start the conversation, please send an email to michael@chefsteps.com with:

  • A link to your portfolio or to one or more sites where we can see what you’ve built. If it was a collaborative effort, let us know what is yours.
  • A paragraph or two about why you think you’d be a great fit.
  • Take a look at the existing chefsteps.com and suggest 1 to 3 things that you think should be the highest priority to improve.

We look forward to hearing from you, and please send this post to anyone you think might be interested!

Why Sous Vide Is The Best Bargain In Cooking

When home cooks first hear about sous vide, a common reaction is “that’s nice, but I’m not going to spend a bunch of money on a newfangled, expensive gadget.” I encourage everyone to be skeptical of new kitchen gear, but I think in the case of sous vide, a circulator is a fantastic bargain for the home cook. Here are a few reasons why:

  1. Have you ever thought about getting a second oven for entertaining? The minimum you will spend on that is around $800 plus installation; for a nice one you can easily spend five times that much or more. An immersion circulator will only set you back between $400 and $1100 dollars depending on the model. (We have several available in our store, and purchasing directly from ChefSteps help us keep the program free-to-learn.)
  2. That second traditional oven will take up valuable space in your kitchen all of the time, while a circulator and plastic tub can easily go in your storage room or basement when not in use.
  3. The circulator opens up a whole new set of capabilities and creativity you’ve never had before. A huge variety of foods can be cooked to perfect, consistent doneness without losing flavor to the cooking medium. You can add marinades or brines right in the bag to enhance the flavor.
  4. Sous vide cooking can often be done well in advance, making both weeknight suppers and entertaining a snap. When you are ready to serve, a quick reheat and possibly a sear in a hot pan is all that is needed.
  5. Sous vide isn’t just for meat! Everything from asparagus to beans, potatoes to ice cream base are better than ever before. If you love eggs soft-boiled or poached, sous vide gives you incomparable control over the texture of the yolks.
  6. In the past, information about how to cook sous vide was difficult to come by and often geared towards restaurant chefs. The ChefSteps course makes all of the information accessible and puts it in a context that anyone can use.

You might be wondering, “but what about the vacuum sealer?” True enough, professional vacuum capabilities are awesome and open up even more possibilities for creativity and food preservation. But the essence of sous vide is accurate control of heat; you can improve your cooking dramatically using an immersion circulator and a FoodSaver-type edge-sealer or even improvised packaging in a ZipLoc bag.

There you have it. In my opinion, sous vide isn’t some space-age technique only for the gadget-obesessed, well-heeled cook. It is eminently practical, reasonably priced, and a perfect complement to your existing stove, oven and grill. Anyone who enjoys cooking will find it changes the whole game.

So what do you think? Have I convinced you? And if not, what holds you back from getting started with sous vide?

ChefSteps Recipe Printing Is Now Enabled!

You Asked, We Listened.

Good news! You can now print out a hard copy of any of our recipes. At the top of a recipe, you’ll see a print link in the navigation bar (or you can just use the print menu item in your browser), and it will print in a somewhat reasonable format with smaller images; leaving out excess stuff in the header, etc.

It isn’t consistent between browsers yet, the best experience seems to be in Firefox, but they are all a lot better than printing the raw page. Please give it a try and let us know (by posting on our forum) how it worked and what you’d like to see improved!

Thank you,
Michael Natkin and the rest of the ChefSteps Team

What I’m Doing At ChefSteps. And Maybe You Should Be Here Too.

 

Let me introduce our newest team member at ChefSteps. Michael Natkin has come on board to lead our software development. Michael has three decades of software experience on projects ranging from wiggling dinosaur bellies for Jurassic Park to a long career working on Adobe After Effects. He’s also created his own very successful blog (and cookbook), Herbivoracious. We like to tease him a bit about the vegetarian thing, but it is cool to bring on a software guy that can also hold his own in the kitchen and the blogosphere. Michael is going to be building out a software team, so I thought I’d ask him to say a few words about his experience so far at ChefSteps and what he’s looking for in a new hire. Take it away, Michael…

A few weeks ago, I climbed a few flights of stairs and found myself in a utopia at the nexus of cooking and technology. From the minute I met Chris, Grant, Ryan and the rest of the ChefSteps team I knew I had to create a place for myself here. I left my (fantastic) job at Adobe because I wanted to focus on food, aiming to open a small restaurant. Little did I know I’d find a place where I can put my passions for both food and technology into play.

Let me describe what you see when you walk in here. ChefSteps is located in 4000 square feet of industrial space underneath Pike Place Market. Just about any food product we might want is within a few hundred yards. When you walk in the front door, you are in a kitchen, but not like any you have ever seen before. Sure, there is a stove, but there are also centrifuges, rotor-stator homogenizers, immersion circulators by the case lot, and cabinets full of every imaginable hydrocolloid.

A typical day around here is amazing. At any given time, Ben may be working on a novel vegan egg replacer while Grant is preparing an 18 course tasting menu for six and advising Nick on a packaged food project. Ryan and Kristina are shooting and editing incredible video and photos for the site. Chris is leading a session for future blender products with a team from Waring; oh and Neal Stephenson happens to be part of the group doing the brainstorming. On day 2, blenders are disassembled, Nathan Pegram quickly fabricates dangerous new prototype accessories in the machine shop, and then everything is welded back together and quickly torture tested in the kitchen.

We are definitely in startup mode. The business ideas are flowing almost faster than we can write them down – and they are driven by a passion to share the knowledge and talents of the team here with anyone that wants to know how to cook more delicious food. That’s a mission I can get on board with. For certain, the cooking courses that are in beta now are a key part of the picture, and there is a metric ton of development to be done to make the site great.

I’ve signed on as the lead developer, and I couldn’t be more excited. And I need to hire at least one more person whose skills are complementary to mine. I know how to lead large software projects, keep them customer focused, write a ton of code, and flow with ever-changing priorities. Because I come from a shrinkwrap software world, I don’t know a modern web stack in great detail. So the person I need to hire next knows Rails and JQuery like the backs of their hands. Bonus points for Heroku. They are a monster programmer that when pointed in the general direction of a target will seek and destroy it, clearing out any obstacles in the way. For now at least, the team is on-site so I’m only looking for someone in the Seattle area.

If that sounds like you, please send well-thought out answers to the following two questions to michael@chefsteps.com.

  1. Where can I see your work on the web? Give me the URL, tell me what you think is great about it, and let me know exactly what your contributions to the project were if it was developed by more than one person.
  2. Take a look at the existing ChefSteps site, paying special attention to the parts of one course we have up so far. What are the top three features that you think we should work on next?
We are ready to move fast to create this team, so if you think this sounds like an amazing place to work – well, you are right, and if you have the skills, please get in touch ASAP.