Saturday, January 28, 2012

Leadership Lessons I Learned From My Dogs

I know there are a lot of useless "everything I need to know..." lists including plenty about what people have "learned" from their dogs. In fact, there's even an entire management book on it. There may be a few useful entries on these lists, but usually, they feel as though the authors were adding filler to reach some specific number of lessons or to make the list as big as possible.

At risk of adding yet another entry to the over-abundance, I assembled my own list of leadership lessons that I learned from my dogs. Each item in the list is experience-driven, originating in the confluence of personal reflection on leadership experiences at work and trying to take care of my dogs. Many of them came from morning and evening walks when the dogs are trying to find a good place to poop and I am preparing mentally for the day ahead or winding down from the day now passed. This is why there are precisely 7 entries, rather than 5 or 10 or 100.

These are the genuine lessons in leadership my dogs taught me:
  1. Encourage desired behavior by using rewards. The best way I have found to get my dogs to sit on command is to reward them when they do it. This is called operant conditioning, in the form of positive reinforcement. The important observation is that punishment is not an tool for extracting desired behavior. The same goes for people. If you want to, for example, get people to be collaborative, the best way to do so is to reward the behavior. It is also worth understanding negative reinforcement. A product that breaks easily even though it shouldn't will result in a lot of support calls and lost customers. The pain associated with each call and lost customer is encouragement to make your product more resilient.
  2. Different rewards are appropriate at different times. Sometimes a dog needs a big, beefy treat, like when it is learning a completely new trick. Sometimes it only needs a pat on the head, like when it is performing a behavior it has internalized. With people, big rewards are needed when, for example, cultural change is initiated. Smaller rewards are needed after the desired culture has been established and the person exhibits according behavior.
  3. Punishment is appropriate to stop misbehavior. Trying to teach a dog to stay out of the street by making them come to you with a treat whenever they start to walk into the street really just teaches them that they can get a treat by walking into the street. Punishment sucks for everyone involved, but it is an effective tool for stopping undesired behavior. If you shout at a dog when it walks into the street, it will quickly learn that there is a negative consequence for this action. When people are fighting at work, the most effective way to put an immediate stop to the behavior is to punish it. To state the obvious, combining multiple stimuli is more effective than applying a single one. This risk with punishment is that when the enforcer is removed, the opportunity for the undesired behavior to return surfaces. If we stop people from fighting with punishment, then help them to observe the rewards of collaboration, we have an impact that lasts much longer.
  4. Everything is about influence. At this point, it is probably clear that the overarching statement of this post is that leadership is effective application of influence. Keep in mind that influence is not just an outbound process. My dogs try to influence me all the time. When they get in trouble, they really do make puppy eyes and it's incredibly hard to punish bad behavior when the puppy eyes are on full blast. Influence goes in all directions. At work, our peers influence us, our employees influence us, our bosses influence us, our customers influence us, our suppliers influence us, and so on.
  5. Keep on schedule and follow through with commitment. When I don't keep on schedule and follow through with my commitment to my dogs, they pee on the floor. Having a schedule makes their lives predictable, so they know when they'll get to go outside. My commitment to them is to take them out on that schedule. When I don't, I'm punished, even though the dogs aren't punishing me on purpose (at least I hope not!). When a commitment is made to an employee or customer, we must follow through. Otherwise, they will justifiably leave us. Or if they're crazy enough, they might pee on our floors.
  6. Sometime you just have to pick up poo. Dogs poop. In fact, everyone poops. As a dog owner, it's my responsibility to pick up their poop. Things don't always go right and as leaders, sometimes we have to clean up messes even if we didn't directly cause them. It comes with the territory, so if one is not okay with cleaning up from time to time, they should reconsider whether leadership is for them. And we should all keep in mind that it's perfectly fine not to be a leader! The decision depends on our aspirations, goals, and personal values. Those of us who do wish to be leaders have a responsibility to create the best situation possible, so we must use our skills of influence to reduce the occurrence of messes.
  7. Their health is important to our health. Having pets purportedly has many health benefits. I don't know if they really reduce stress (try telling me that when I'm picking up poop), but I certainly enjoy walking with them, playing with them, and telling funny stories about them. As a leader, all the people around us enhance our ability to do whatever we do. The health of a leader's career depends on the health of those around him or her. When our customers are not doing well, neither are we. When the people we work with become unhappy or sick, our capacity to work towards a goal dissipates. It is important to take care of those around us and to be a force for good in their lives.

Sunday, January 22, 2012

Startup Weekend: Lessons and tools

There are innumerable lessons to be learned through the course of any Startup Weekend. Here are the key take-aways from my first experience:
  1. People first: You're going to spend 54 hours working closely and under high pressure with a group of people you (probably) haven't met before. Make sure you pick people you'll enjoy working with. A great idea is exciting, but choosing the right people will make or break your weekend. This also means you should try to find people who are looking to get the same thing out of the weekend as yourself.
  2. Bring your own skills: You don't need to be an expert in everything, but don't set your project up such that it will fail if you don't have access to specific talent. Several teams didn't have any prototype whatsoever when demo time came around and this hurt them in the judging. If you have no technical background, dabble in HTML, which in many cases will be enough for you to mock something up. Or familiarize yourself with the process of off-loading the work to others through oDesk or your personal rolodex. If you are technical, but have no business skills, have some resources prepared that can guide you through the steps needed to assemble a pitch deck. For Startup Weekend, things don't need to be perfect - they just need to be done.
  3. Leave your ego at the door: A big ego has no place at Startup Weekend. This will drive people away from your team. Let someone else be the expert. One of the devs I worked with was less experienced than myself and preferred to use a technology I hadn't used in the past, but we went ahead and chose that. I felt that it would make the experience more enjoyable for the group and that it would be an opportunity for me to learn something new. Throughout the weekend, I probably asked him questions every thirty minutes, but I didn't have a choice since we were in a time crunch. In the end, I felt that even though I was slower, we were fairly productive as a team. Plus I learned a lot from him.
  4. Also, leave your way of doing things at the door: Remember that you're working with new people and each of them are used to doing things in their own way. Everyone needs to be flexible and coalesce around a common approach. No one has to agree about whether any ways is right or wrong, but everyone has to be willing to go with one approach during the next 54 hours.
  5. Don't wait: Make sure that throughout the weekend, you keep the time limit in mind. You might feel like you need to hammer out the monetization scheme before going out and getting feedback, before giving the devs implementation tasks, etc. This is a mistake that will lead to a missed deadline. Devs can and should get started on something. The same for designers and business people. Don't worry about whether any of it will be thrown away. Try to work smart so that there are re-usable pieces that can be applied after your customers tell you your idea sucks and you have to change it. Remember that you're just hacking together a rough prototype.
  6. Relentless focus: It's unbelievably easy to get caught up in getting to know your teammates better, pontificating about the virtues of different approaches to the project, etc. Everyone needs to be incredibly focused on whatever they're responsible for. It even goes as far as (politely!) turning away mentors when you have to. Trust me, they'll understand.
  7. You can call a turd sacred, but it's still just a ball of poo: You're in prototype mode the entire weekend. 85% or more of what you create during the weekend will be thrown out if you even continue with the idea at all afterwards. Don't treat anything as sacred. You built a sweet app, but the target customers don't have iPhones? Throw it out. You came up with a brilliant way to trigger viral marketing, but you can't get the viral coefficient to be greater than 1? Throw it out. This doesn't literally mean let the ideas fall off the face of the Earth entirely, but for the weekend, focus on what works. You can come back to all the other ideas later.
  8. Remember, it's only a weekend: Startup Weekend takes place during the weekend and lasts only 54 hours. This means you're not missing work, you're not making any career commitments, you're not taking financial risk, etc. This is a great environment in which to experiment, learn new things, and meet some great people. On Monday, you'll get to return to your day job, where you report to your manager, have health insurance, and have a steady paycheck. Or maybe you won't... by your own choice. ;)
  9. Bring water: This pointer is simply related to the fact that you probably aren't familiar with the facilities you'll be working in, so be sure to bring some extra supplies. There wasn't enough water to go around during my first Startup Weekend, so everyone was a bit parched. Perhaps you'll find that you need an extra jacket because the heater isn't working. Just be sure to bring what you need to be comfortable and focused.
The tools and services we ended up using during the weekend included the following:
  • Lot's of sticky notes and pens: We used these to brainstorm and track ideas as well as tasks.
  • github: Online code repository for source control.
  • php fog: PHP host that helps you get your service up and running in minutes.
  • CodeIgniter: PHP framework to help build web apps.
  • MySQL: Database.
  • HTML5, JavaScript, CSS: Standard technologies for building web clients.
  • jQuery: A JavaScript library that helps make your JavaScript coding more productive.
  • Google Maps JavaScript API: Useful for presenting location-based information.
  • Dropbox: We used this extensively to share documents and other miscellaneous files.
  • SurveyMonkey: We sent a survey out to poll potential customers about our idea.
  • iPhone Camera: We used phone cameras a few times to capture information, including to record the product demo that was included in our presentation.
  • Business Model Canvas: The business model canvas helps map out the elements of a business model and identifies areas in which assumptions need to be validated.
  • The design team also used a variety of tools, though I'm not sure what.


Follow my Startup Weekend Seattle experience through the following progression of posts:
  1. Initial thoughts
  2. Pre-Startup Weekend bootcamp (Jan. 12, 2012)
  3. My pitch idea
  4. Day 1 of Startup Weekend Seattle (Jan. 13, 2012)
  5. Day 2 of Startup Weekend Seattle (Jan. 14, 2012)
  6. Day 3 of Startup Weekend Seattle (Jan. 15, 2012)
  7. Post-Startup Weekend lesson summary (this post)

Tuesday, January 17, 2012

Startup Weekend: Day 3

I arrived at the Hub on day 3 of Startup Weekend to find that two more team members tapped out. The dev who had been programming the iPhone interface sent us an email mid-morning because there was too much snow in the streets and we simply never heard from the dev who had been working on the HTML. The only HTML code that was checked in was the setup I had prepared the night before and I was thankful that I had started it.

The biz team had sent a survey the night before and I forwarded it to a few friends. Several of them actually wrote me a quick message in response showing their support for my involvement with this project, for which I'm thankful:
  • Very cool - Good luck! - R.B.
  • I loved the idea. I will be a user. - R.S.
  • Cool, Hakon. I like the idea and love that you are building it! - M.D
Messages like that are really nice and were good motivation for the day ahead. With half the dev team gone, the remaining two of us quickly synced up on the situation and started attacking the challenge of getting the prototype ready for the 5pm demo right away. Through the day, we were heads-down and mercilessly turned away anyone who might distract us. Unfortunately, this included mentors, who I would have liked to have spent more time with, but we had our priorities and this was time for coding. We weren't going to let our team down by not delivering a prototype.

Part way through the day, the graphics came in and were beautiful. I've never worked with artists or designers before and it was a great experience to do so, seeing their expertise in action. The truth is, we didn't approach our product as something that was meant to solve a problem, as would a traditional startup. Rather, our aim was to create an experience that introduced joy into people's lives. The art and user experience design were integral to making this happen.

Since we were so tight on time, we knew that on the dev side we were going to have a pretty rough prototype. However, we wanted something more complete for the demo. One of our designers had done mock-ups of the app to show the user experience and to guide the dev team in what to implement. We took the mock-up and extended it to present a series of steps that captured the user experience. This was recorded on video and included in the demo. It came out great!

Through the day, the biz team was working out details in the concept and putting together ideas for the presentation. The presentations were alloted 4 minutes each with time for Q&A from the panel of judges. The team worked on a slide deck and for most of the day, we didn't see them since they were practicing and refining the presentation.

My partner dev and I coded right up to presentation time. Just as presentations were starting, we wrapped up the last bit of functionality we thought was required for the prototype and cheered a bit because we had actually gotten it done! We quickly created a bitly link and ran it over to the biz team so they could include it in the presentation.


My fellow dev, Michael, working right up until presentation time!

As the presentations began, the biz team kept practicing. In short time, we were next up to present. Naturally, disaster struck as the computer on which the presentation was hosted refused to display to the projector. The organizers allowed us to swap places with the proceeding team and take another shot at setting up the presentation. Our team scrambled, transferring the presentation to another computer and making another attempt at getting it on the screen. Fortunately, it worked this time and we were up!


The illustrious judge panel (left) and the exhausted audience (right).

More disastor hit as we began presenting because at that point we were simply too tired to give a coherent talk. So we bumbled a bit with the informational portion of the presentation, but luckily the sense of the concept was more or less conveyed. The video lined up in the presentation and did its job of showing the experience the product creates. We never made it to the deeper explaination of the business model and customer validation, though we got a little of that out in the Q&A session. While we did an awesome job through the weekend, the steam ran out at the end and there was no way we could rank among the top projects. However, I had such an incredible experience and enjoyed working with the team so much that it didn't matter to me.


The presentation (left), including a pre-recorded video (right).

After presentations, we had a chance to talk to our fellow teams congratulating one another and getting more information about the cool things they had created over the course of 54 hours. The room was alive and everyone seemed pleased with what they had accomplished in such a short time.

A few minutes later, the judges came back and began announcing winners. They started with an honorable mention for best design. Then they moved on to best experience. To my team's astonishment, they proclaimed that we had won! It's hard to describe the incredible feeling of that moment, when we weren't expecting anything and yet were awarded one of the top spots in the competition! The judges continued with awards for best presentation, best market validation, and best overall. Afterwards, our team regrouped and the emotion spilled over. We were estatic!

We wound down the night with a beer at a bar across the street from The Hub, discussing the weekend and our experiences. A day later, we were notified that an article had been written up on GeekWire summarizing the weekend and mentioning our team as one of the winners.

This was an incredible end to an incredible weekend. I was completely amazed as I drove home, reflecting on everything that had happened. No amount of reading or conversation could have equaled the experience of actually doing it. I had a blast and can't wait until the next Startup Weekend! If you're around, I'll see you in Redmond!

Note: If you enjoyed reading about my Startup Weekend experience, check out my buddy Dwight's write-up to get another perspective. Dwight produced all the amazing art and branding for our project. You can get a third perspective from Katie, the dev who left the team the first night to help a team with no devs, at her blog.


Follow my Startup Weekend Seattle experience through the following progression of posts:
  1. Initial thoughts
  2. Pre-Startup Weekend bootcamp (Jan. 12, 2012)
  3. My pitch idea
  4. Day 1 of Startup Weekend Seattle (Jan. 13, 2012)
  5. Day 2 of Startup Weekend Seattle (Jan. 14, 2012)
  6. Day 3 of Startup Weekend Seattle (Jan. 15, 2012) (this post)
  7. Post-Startup Weekend lesson summary

Sunday, January 15, 2012

Startup Weekend: Day 2

Day 2 of Startup Weekend kicked off at 9:30 am and about half the team was at The Hub when I got there. We started going over the idea again to figure out the types of technologies the dev team would need to set up (e.g. do we need a payment system? a database? etc.), but there was some thrashing since each person had a slightly different vision of the product. And of course, the large size of our team didn't help the situation. Fortunately, there were some things that overlapped regardless of the vision, so the dev team wasn't blocked. As a group, we agreed that an iPhone app would probably be the best way to present the experience we wanted to capture and we had a dev with iPhone experience, so he started setting up the basics. Another dev and myself started putting together a database and a RESTful service in front of it. The last dev really wanted to work on HTML5 and though the value of that work wasn't clear for the purposes of the event, at the time we had less work than could keep us all occupied, so he started working on that.

By 11:30 am, the biz team hadn't yet hit the streets to validate the idea with customers. The problem was primarily around figuring out how to monetize the product. To help resolve the deadlock, we regrouped to determine what assumptions we were going to start out with. We listed a number of key questions on a whiteboard such as "do our customers have smart phones?" and spent 30 seconds voting on the initial assumption for each one. Several questions were unnecessary to answer at the time including several that required other questions to be answered first. After doing this, we had our initial set of assumptions and could continue making progress. Some time shortly after that, the business team set out to talk to coffee shop owners and the dev team continued chugging away. In truth, identifying the right questions and the initial assumptions is not an easy task, or at least not when it's one's first time doing it.



The business team hard at work (left) and our assumption board (right).

Although there were challenges, something we did that was really important was to trust one another to deliver on their tasks. As the dev team, we trusted that the business team would deliver us a business model to implement, while they trusted us to deliver a prototype in time for the demo. The design team created an experience and trusted us to bring it out in the product. Likewise, the business team trusted the design team to bring the experience expressed in the vision to life. While we often worked together, giving feedback across teams and aligning ourselves, there was significant trust involved, which ties back to the importance of individual picking the right team and the team picking the right members.

Unfortunately, we had some additional attrition on the business side of the team by the afternoon. Two folks departed, leaving us with 10 people. At that point, we had 3 business people, 2 designers, 4 devs, and the team leader, who worked on both the business and the design (he's a designer by trade). Again, it was sad to see the departure, but probably better for everyone's overall experience.

As the day progressed, we ran into an issue on the dev team. Since only one team member had a Mac, we quickly got bottle-necked on iPhone development. We were able to whip out the backend fairly quickly thanks to its simplicity and the awesomeness of phpfog. When that happened, those of us who did not have implementation tasks made sure the backend was well-documented and ready for integration and researched services we might want to rely on such as various payment systems.

Unfortunately, I had to head out early around 5:30 pm due to a family emergency. Two other devs decided to take off at the same time as it had started snowing and they didn't want to get caught unable to reach home. I was able to come online later in the evening and found that the business team had sent out a survey using SurveyMonkey. I filled out the survey and forwarded it on to a select set of friends who I thought would be interested in responding (thanks to all who filled out the survey!).


Snowing in Seattle during Startup Weekend.

As I was reviewing the day and emails that were sent this evening, something disastrous dawned on me. There's no way we'll have the prototype for tomorrow. With only one iPhone developer, we're out of luck going down that path. I refuse to give up though. We will have a prototype to present, even if it's a big ball of tape and glue. The HTML5 code was never checked in, but it might be what we need to pull things back together. Since I don't know what the status of that code is, I started putting some pieces together myself to make sure we'll have a foundation to work from tomorrow when we'll need to seriously crank things out.


Follow my Startup Weekend Seattle experience through the following progression of posts:
  1. Initial thoughts
  2. Pre-Startup Weekend bootcamp (Jan. 12, 2012)
  3. My pitch idea
  4. Day 1 of Startup Weekend Seattle (Jan. 13, 2012)
  5. Day 2 of Startup Weekend Seattle (Jan. 14, 2012) (this post)
  6. Day 3 of Startup Weekend Seattle (Jan. 15, 2012)
  7. Post-Startup Weekend lesson summary

Saturday, January 14, 2012

Startup Weekend: Day 1

I'm finally about to go to sleep after a long evening. I can already say that Startup Weekend has been one of the most incredible experiences I've been through and I feel as though I've already gotten my money's worth in what I've learned in the 7 hours I spent there today.

Startup Weekend Seattle kicks off

Before pitches began, I was able to practice my pitch a few times. People liked it and those who had heard my previous ideas felt that this idea had more footing. I hate when people say "my product is like X for Y", but the immediate reaction of several people was that Keynote Reputation was like Yelp! for people. It does kind of make sense. The analogy isn't enough by itself, but it helps the listener get an immediate mental model of what the idea is. So, in the end I included the analogy in my pitch, which you can check out below:


My (nervous!) pitch

I felt that the pitch itself went well enough, considering that I was extremely nervous. Each of us who pitched had 1 minute to describe our idea in an effort to convince others to help us create a business around it in the next 48 hours. Afterwards, we were given some time to mingle and vote on the ideas. As I walked around, people remembered both me and my idea. Looking for a deeper understanding, I asked how people remembered. As it turns out, the analogy that I didn't want to use ended up being a key factor! The stickers I made also helped.

After voting, my idea ended up with 4 our 5 votes, one of which was my own (we were each given three votes). This was not enough to make it into the top 13, so my idea wasn't one of the ones that became a weekend project. I'm actually pretty pleased with the results, given that there were about 60 pitches and many got no votes. All in all, I was quite impressed with the pitches. There were a lot of great ideas and passionate people.

Since my idea didn't make it past voting, I had to find a team to join. I ended up going with an idea I was pretty excited about and had wanted to work on anyway. In a nutshell, it's an app to leave a friend a gift in a specific location, with the friend getting a notification of the gift when they are within a certain proximity of it.

Aside from the pitch experience, there were three important lessons I'd like to share. The first is that large teams can be difficult to manage. We ended up with 13 team members to start (hmm... I'm not superstitious, but it's an interesting coincidence that it's Friday the 13th, there are 13 teams in the program, and my team had 13 members). There was a suggestion that we split the team in two and have two independent teams work on the same idea. We did not do this though, being optimistic about our ability to work together and make progress on this idea. Easier said than done, but I think we're doing well.

The second lesson was that identifying assumptions and figuring out how to iterate on an idea can be difficult. We found that our conversation frequently fell into details without recognizing that we were making assumptions that needed to be validated. Even in just the roughly 3 hours that we spent as a newly-formed team, we found that we had to modify the idea. This is great though! One of the benefits to having a large team is that we have lots of great input from people with different backgrounds and expertise. The trick is to keep it well-managed.

The last lesson is related to the mention of falling into details above. When talking about the idea and the business, we need to be willing to step out of our traditional roles. When in the depths of solving technical problems, a lot of technical detail is usually appropriate. However, discussing implementation details is not appropriate when trying to figure out the vision and the business model. As the team tried to narrow in on a vision for the idea, there were several times when we started talking about the technical implementation, marketing strategy, sales, design, and more to a degree that was distracting. For the vision, I would argue that these specifics are not appropriate at all. The vision simply captures the fundamental elements of what you want to create. For development of the business model, these various aspects should get more attention, but no more or less than needed. Personally, I found that I needed to make a conscientious effort to step back from the deep technical details I'm used to working with and see things at a higher level.

Before the night was over, one of our devs decided that the team was overcrowded and respectfully bowed out to join a team that was had no devs. We were sad to see her go, but I believe the decision will probably lead to a better experience both for herself and for our team, which was then down to the still large size of 12 people. I expect that we'll face some new challenges in addition to the ones mentioned above because of the size of our team as we move forward, but I think we'll manage through it and come out with something really great in the end.

I can't wait for tomorrow!


Follow my Startup Weekend Seattle experience through the following progression of posts:
  1. Initial thoughts
  2. Pre-Startup Weekend bootcamp (Jan. 12, 2012)
  3. My pitch idea
  4. Day 1 of Startup Weekend Seattle (Jan. 13, 2012) (this post)
  5. Day 2 of Startup Weekend Seattle (Jan. 14, 2012)
  6. Day 3 of Startup Weekend Seattle (Jan. 15, 2012)
  7. Post-Startup Weekend lesson summary

Friday, January 13, 2012

Startup Weekend: Get the right people on the bus

According to Jim Collins, the first step to building a great business (actually, turning a good business into a great one, but I think the concept still applies) is to "get the right people on the bus". At Startup Weekend, this starts with an idea pitch to convince other people to work with you on an idea you have. I've iterated over lots of ideas over the past two weeks, getting feedback from everyone I could about what is interesting and what is not, and something finally stuck at the last minute. It's about helping experts build their reputations and helping event organizers find speakers for their events. Here's my pitch:

You’re an expert. You’re good at what you do and you love it. But I don’t have to tell you that because you already know. The problem is that other people don’t! There are people looking for you right now and they don’t know how to find you.

Real-world events, big and small, need experts every day and each event is an chance for experts to build solid reputations. There is a huge opportunity to change the way experts connect with the people who need them for real-world events, while building their reputations.

The team name is Keynote Reputation and we need expert developers to make it real, expert designers to make it magical, and expert business people to make it profitable. Come talk to me to change the way reputations are built.


Hopefully it doesn't seem too gimmicky, but I've also created some stickers that will be useful to other attendees and hopefully get people interested in Keynote Reputation early on. Here's a snapshot:



Follow my Startup Weekend Seattle experience through the following progression of posts:
  1. Initial thoughts
  2. Pre-Startup Weekend bootcamp (Jan. 12, 2012)
  3. My pitch idea (this post)
  4. Day 1 of Startup Weekend Seattle (Jan. 13, 2012)
  5. Day 2 of Startup Weekend Seattle (Jan. 14, 2012)
  6. Day 3 of Startup Weekend Seattle (Jan. 15, 2012)
  7. Post-Startup Weekend lesson summary

Pre-Startup Weekend bootcamp

I went to a pre-Startup Weekend "bootcamp" tonight and had a pretty good time. While there were a few folks who had been to past Startup Weekend events, I felt like most of them were in the same first-timer boat as me. There were probably about 40 people (out of 120 registered for the main event) in attendance. The aggregate skill set was a bit skewed towards software development probably due to the bootcamp being somewhat developer-focused. However, people talked about everything from Google App Engine to business models to pitches.

Since I really want to pitch an idea to get the full experience of the event, I've been trying to come up with ideas over the past couple of weeks. I had six ideas I was considering, some of which I think would be pretty fun to work on, but after getting feedback from colleagues, friends, and new acquaintances from the bootcamp, I'm not convinced any of them will attract much interest from other folks at Startup Weekend. At this point, I think I need to just go with one and cross my fingers. Even if it doesn't come out well, the practice will be good for me and I'll still be excited about working on another project.

Something else I've been doing in preparation for the weekend is searching for tools to help manage the project and assist with business development. In terms of management, my favorite tool is Trello. I already use it for personal stuff and it's so easy to use and share that I think this will be a great help during the weekend. One of the cooler customer feedback tools I'm hoping I'll get a chance to try is aytm (ask your target market). It's a very focused survey tool that lets businesses survey their target audience.

At the end of the weekend, I'll write a review of the experience and share a list of the tools that we actually used. I'm excited!


Follow my Startup Weekend Seattle experience through the following progression of posts:
  1. Initial thoughts
  2. Pre-Startup Weekend bootcamp (Jan. 12, 2012) (this post)
  3. My pitch idea
  4. Day 1 of Startup Weekend Seattle (Jan. 13, 2012)
  5. Day 2 of Startup Weekend Seattle (Jan. 14, 2012)
  6. Day 3 of Startup Weekend Seattle (Jan. 15, 2012)
  7. Post-Startup Weekend lesson summary

Sunday, January 8, 2012

An Example Technical Interview

Previously, I outlined the typical interview day at Microsoft. In this post, I'm going to give an example of a technical interview with a team member. When reading through the example, it is important to keep a few things in mind:

  1. Every interview is different. While there may be many similarities between different interviews, every interview will be unique. Every interviewer has a different style and every candidate has a different background. Various other factors come into play as well like time of day. Interviewing in the morning can be different than interviewing in the afternoon, especially candidate or interviewer is not used to waking up early.
  2. The questions asked will vary depending on the position and the level it's at. The example here is meant to represent the kind of interaction that would take place with someone who is interviewing for a developer position requiring a college degree and some experience. This persona is assumed purely to facilitate the discussion. Interviews for positions at lower and higher levels follows a similar pattern. In many cases, the same questions will be asked of people at different levels with different expectations for the responses given. In response to the persona, I'd also like to point out that a college degree isn't an absolute requirement for most positions. It does help with getting an interview in the first place though.
  3. The important part is the method, not the specifics of the example. I would highly recommend against memorizing problems and solutions. Knowing how to solve problems is the key to success.
  4. This example focuses on the technical interview.Some of the interviews will be technical in nature, but won't involve coding. Some won't be technical at all and will focus entirely on the candidate's personality. While it may happen on occasion, don't expect that every interview through the day will follow the pattern of this example.
The example is broken down to 5 distinguishable segments: (1) the warmup chat, (2) the easy filter question, (3) the real coding test, (4) the problem solving test, and (5) question time.

1. The Warmup
The warmup is all about helping the candidate to relax a bit. We all know interviews are nerve-wracking and we want to test the undiminished skill of the candidate. In the actual job, there will be many times when there is intense pressure and the team must be able to operate under such circumstances. However, we don't want candidates to be worried about whether they'll get the job. Rather, the pressure should come from the limited time they have. This is more like the deadline-driven pressure they will face later.

Interviewer: Hi, my name's Alice. Pleased to meet you, Bob.
Candidate: Hi Alice. Likewise.
Interviewer: I hear this is your first time in Seattle? How are you liking it so far?
Candidate: It's nice. It doesn't seem as wet as I thought it was going to be.
Interviewer: Yeah, it does actually rain a fair amount, but it's more like drizzle than downpour. So, have you a chance to talk much with other folks about our team and our product?
Candidate: I actually ran out of time in the last interview, but I got a high-level view when I talked to John this morning.
Interviewer: Did you find anything to be of particular interest?
Candidate: Yeah, the asynchronous processing seems really interesting. I've done a bit of that in the past and there are some good challenges around it.
...

What's going on here is a bit of selling the candidate on Seattle, finding out what the candidate's interests are, seeing if there's something for the candidate to get excited about on the team, and a friendly conversation about technology/problems the candidate is interested in. In all, this should be about 5 minutes. 10 minutes would be long since that would take up over 15% of the time allotted to the interview.

2. The Filter
Next comes a simple whiteboard problem that is meant to see whether the candidate should be in the interview at all. This usually isn't an issue since pre-screening over the phone is a fairly effective means of identifying whether the time and financial expense that goes into bringing someone in for a full interview should be paid.

Interviewer: Alright, I hate to interrupt our conversation, but we should really move on. Are you ready for some whiteboarding?
Candidate: Yeah, let's go ahead.
Interviewer: Great. Can you write some code to reverse a list?
Candidate: Sure. In what language?
Interviewer: What are you most comfortable with?
Candidate: I'm pretty comfortable with C, Java, and Perl. I think Java would be my preference.
Interviewer: Okay, perfect. Go ahead with Java then.
...

When you do code interviews, interviewers will usually ask you to work in whatever language you're most comfortable. Of course, there are some cases in which that won't be true. For example, when the interviewer is only familiar with languages similar to C and your preference is to work in LISP, some accommodation is probably in order.

The filter problem should really take between 5 and 10 minutes, including some validation of the solution. When candidates struggle with this one, it's usually a good indication that they aren't quite ready for the job they're applying for. Again, keep in mind all interviewers are different and not all of them will start with a simple problem. Whatever the case, try not to think too much about the mechanics of the interview and stay focused on solving the problems.

Sometimes, poor results on a filter problem will lead to cutting the remainder of the day short. If this happens, it's nothing to be embarrassed about. It just means you need to continue building your skills and come back for another try later (assuming that's what you want). In most cases, shortening the day is the right thing to do since it's respectful of both the candidate's time and the interviewers' time.

To practice for this type of question, my recommendation is to find as many simple problems as you can (or make them up) and try solving them on a whiteboard while you time yourself. If you can, get a friend or two to watch while you do this and point out mistakes. You might get a face full of humble the first time you do this, but if the job is worth it, this practice is also worth it. Over time, you'll find that you get better at solving these kinds of problems quickly as you develop a methodology for cranking out a validated solution. The added benefit is that methodology will also be applicable to...

3. The Real Coding Problem
This is the part of the interview that is really meant to challenge candidates in terms of their ability to solve algorithmic problems with code. This will require a solid understanding of more advanced concepts like pointers, recursion, concurrency, etc.

Interviewer: Looks good. So, here's another one. We need a dictionary class that can print the word list in alphabetical order. Can you implement the class for me?
Candidate: Yeah, definitely. Since we need to print the list of words, I'm assuming the dictionary is dynamic. Can I also assume that word-lookups are frequent and printing the list is relatively infrequent?
Interviewer: Yeah, that's fine.
Candidate: Are there any constraints on how long the function takes?
Interviewer: It should be as efficient as possible, given how we've defined the problem. *smile*
Candidate: *smile*
...

Remember to clarify the assumptions you are making in solving this problem. Many or even most of the assumptions will be up to the candidate as long as they make sense. For years I used to think that candidates needed to ask questions to show the interviewer they are careful in understanding requirements. Once I had spent some time on the other side of the table, I realized that while understanding the requirements of what you're creating is, indeed, important, what's more important to the interview is just getting the assumptions on the table as quickly as possible. That will maximize the amount of time spent on coming up with a great solution to the problem and answering any additional questions the interviewer may have.

In the end, this problem shouldn't take too long to solve. The key is to come up with a reasonable solution quickly and code it up. In my opinion, the biggest challenge is deciding on a single solution since there is some ambiguity around the problem. We don't want to fall into the trap of analyzing every trade-off in excruciating detail. What's more important is for the candidate to make it known that he or she is aware of the trade-off. Something to keep in mind is that even though coding is quiet-time for most people, you need to be vocal in interviews so the interviewer is aware of what's on your mind. Interviewers do want to see a candidate's ability to identify and evaluate trade-offs, but not to the detriment of getting through the interview and having a full picture of the candidate's skills. There will be plenty of evaluation of trade-offs in the open-ended design problem.

When the interviewer does need a little more insight, he or she will ask questions. Expect plenty of them both during and after the coding. Some example of questions include:
  • Are you satisfied with your solution?
  • Are there any problems with the algorithm/code?
  • How would you optimize this?
  • What is the run-time?
  • What if multiple thread were accessing it at the same time?
  • What if this were running on a system with limited memory?
  • What is an alternative way in which this could have been solved?
Expect to spend about 20 minutes on this problem. That leaves 20 minutes, which will definitely be needed, for the design problem and 5 minutes for questions at the end.

4. The Open-Ended Design Problem
Do you remember all those open-ended math problems, essay questions, and projects you had to do in high school and college? They just keep coming. Life is full of ambiguity and businesses are built on making good decisions in the face of uncertainty. The open-ended design problem tests a candidate's familiarity with important concepts and their ability to made reasoned trade-offs.

Interviewer: Okay, there's a bit of a change with the next problem. I'd like to talk about how you'd solve a larger problem. You won't need to write anymore code, but feel free to use the whiteboard.
Candidate: Sure.
Interviewer: Assume we have a very large distributed system. A major challenge in building and maintaining distributed systems is debugging. How would you design logging to support this system?
...

This kind of question can be open-ended to an extreme. Clearly, there are innumerable ways to solve such problems. What the candidate needs to do is work with the interviewer to define the constraints. In this case, spending some time exploring the options is expected and, in fact, required. It's not so much about hammering out a solution as it is about the path taken to get there. In this part of the interview, the interviewer will look for the ability to identify and address requirements, limitations, strengths, and weaknesses. The interviewer will also look for the process the candidate uses. Do they try to do all the thinking up-front and stick with the initial solution? Or do they do it iteratively, coming up with a rough concept first and continually refining it?

There will definitely be some weaknesses in the system, just as there will be strengths. The candidate should be able to describe what these are while working towards a solution and give reasoning for why they went one way or the other.

5. Question Time
At this point, the candidate may have a few extra minutes to ask some questions of the interviewer. Some interviewers expect candidates to have good questions and some don't care if they ask anything at all. Personally, I like it when candidates ask questions since I appreciate inquisitive nature and it usually provides an opportunity to know a little more about the candidate. But it isn't important and holds no bearing in the hiring decision. Of course, questions like "how much do you make" are in poor taste and shouldn't be asked. That will be taken as being invasive of the interviewer's privacy and indicative that the candidate is more interested in money than the team, product, and company. The time for money questions will be a few weeks later when, hopefully, you'll get an offer!

And that concludes this technical interview. On to the next hour with the next interviewer!

Saturday, January 7, 2012

I'm going to Startup Weekend Seattle next week!

Those who know me, know that I believe strongly in supporting the entrepreneurial community. There are a variety of reasons for this including (1) that entrepreneurs create jobs, even if just for themselves, (2) that I love seeing people work their way to success, (3) that entrepreneurs are usually very innovative, creating awesome new products and technologies, (4) the list goes on and on...

One of the great Seattle-based organizations involved in developing entrepreneurship is called Startup Weekend. Startup Weekend's mission it is to educate entrepreneurs in communities around the world, with their key tactic being events in which teams collaborate over a 54-hour period to try to put together a business. These events tend to sell out fairly quickly and when the last Seattle event came around I missed the opportunity to participate. This time I signed up early and am happy to say I'll be spending 54 hours working on some innovative project next weekend!

Several people relayed negative feedback to me about Startup Weekend including that participants don't share their good ideas in fear of having them stolen and that you can't learn anything worthwhile in a 54-hour sprint. The first remark concerns me since people who carry this possessive mentality infectiously reduce the trust held in the community. And trust is necessary to build the kind of ecosystem innovation and entrepreneurship thrives in. To address this, we need to forget about what ideas other people are bringing and make sure we each bring our own great idea. Besides, a great idea is worth absolutely nothing - it's execution that creates value (yes, I know reality is not quite so black-and-white, but this is generally true)! Regarding the second remark about an inability to learn, I completely disagree. Life can change in an moment and 54 hours surrounded by motivated innovators and seasoned mentors provides a lot of opportunity for moments. This also completely disregards the fact that Startup Weekend is a fun event!

On the other hand, I've heard plenty of positive responses to Startup Weekend too. There have been a few major success stories like that of Zaarly along with many smaller successes like that of a fellow Microsoftee whose team created an app to help choose a cost-effective commute route, which ended up getting showcased on on the local news! The truth is that success isn't measured by a single metric. Money and fame are great, but if I meet a few new people, learn a bit more about business, and get to create something cool, I will feel tremendously successful!


Follow my Startup Weekend Seattle experience through the following progression of posts:
  1. Initial thoughts (this post)
  2. Pre-Startup Weekend bootcamp (Jan. 12, 2012)
  3. My pitch idea
  4. Day 1 of Startup Weekend Seattle (Jan. 13, 2012)
  5. Day 2 of Startup Weekend Seattle (Jan. 14, 2012)
  6. Day 3 of Startup Weekend Seattle (Jan. 15, 2012)
  7. Post-Startup Weekend lesson summary