Over the last 3 months I interviewed about 30 candidates from all backgrounds with all kinds of expectations. We haven't hired any of those because we have so few positions open that we prefer to be sure than to be sorry.
I also didn't interview another 60 candidates based on their resumes.
Instead of waiting a long time and writing a very thoughtful post, I will write a few thoughts that made us turn down all these candidates. Most of those are my personal biases and perceptions and certainly there are exceptions.
On Resumes...
There are several things on a resume that make me turn down a candidate immediatelly or be way more reluctant at interviewing them:
Too many companies: If you have 10 years on the workforce and worked on 10 companies, that is a bad thing for me. The reason could be because of lack of commitment with long term projects or lack of competence (you might not have been fired, but might have been pushed out). The side effect of not have worked on a project for many years is that you don't understand how products evolve and how the customer feedback loop really works.
Too few companies: 10 years of career all on the same company is bad. It can be minimized if you worked on different projects/teams/groups inside the same company. Ten years working at Microsoft is not bad. Ten years working on Microsoft Excel is. It shows that you don't like change.
Too many technologies: How's it possible that you know 17 languages, 3 server OSes, 7 frameworks, and 23 applications well? I prefer much better when candidates separate the things they are proficient from those that they have some knowledge. Sure you might know Java, C#, C++ and Ruby, but if you think you are great on all of those you probably are not good on any of those and you are bad at self-assessment.
Indirect contribution: "Part of the team", "Helped", "Assisted", etc., shows that you didn't own that component/system. Alone is not a problem, but it makes me really ask questions like "how big was the team", "how much did you contribute on the team", "did you work for another dev manager that designed the system?", etc.
LOOOOOOONG resumes: The best resume I ever got had 1 page and it was well written only with relevant information. The worst resume had 5-6 pages detailing every single feature implemented by this developer on every company he worked for. The reason why long resumes are bad is not they consume a lot of my time, but that it shows the developer doesn't have good communication skills. If he doesn't know how to assess what a hiring manager is looking for how is it possible for him to know how to create features that people will enjoy?
Spell check your resume: No explanation necessary.
Too long as a manager: Most managers end up not being "doers", but "talkers". They talk people into doing work. At a startup we can't have that kind of person. Our CEO answer customer support and find repro case for bugs at his spare time. When I see a developer that worked up the latter (dev... lead... manager... VP) it gets me concerned that he/she lost touch with the technology. This is not a clear cut rule, but it's true 60-80% of the time.
On Informational Interview...
It's a date, don't move to fast: If the first thing you ask me is how much is the salary, the deal is over. If the first thing you ask me is what is the company valuation... over. An interview is like a date. You have to build trust and then start asking more deeper questions.
Don't be cocky: If during an interview you feel that you are "above" us, believe me, it shows. I believe personal fit is as important as competence. If I can't imagine myself working with you day-in day-out, it's over.
Do some homework: The worst thing ever is when a candidate comes and doesn't have a clue what we do. He didn't have the trouble of signing up to our service or even read the content of the website.
Canned answers get you nothing: "I want to be a team member", "I love startups", "I always think of the customer". Ok, unless you can back it up with concrete examples you didn't earn any points and lost time.
Don't BS your technical knowledge: I always worked my career with more interest on breadth than depth, which makes me an expert of nothing. So it's pretty easy to sniff when you say you built a search engine for your product and what you really did was to integrate some existing component and you have no clue of what a search engine really does.
Speak well: It's ok with you are an introvert, shy and don't like to work with other people... If you work at Microsoft! At a startup, you spend a lot of time in an office without walls, bouncing ideas out of each other and sharing your thoughts. If you can't elaborate your thoughts into words, or if you are slow to convert ideas into words, that's probably a bad fit for us.
Don't be cheap/desperate: If it feels that you are "cheap" or desperate to get this job, it certainly raises some flags as to why. It might be that you feel desperate because you think this would be the job of our life, or it could be because you are trying to fake your way into a job.
Ask questions: Joining a startup is a two-way interview. I'm interviewing you as much as you are interviewing me. I expect you to ask about me, about the team, about the startup, about the market, etc (just refer to the first bullet before jumping the gun). If you don't ask serious and thoughtful question it'll make me think you might regret joining us and leave just a few months after.
Then there are other billion things that you should say or not during a technical interview, but I won't write about those.
In my previous life at Microsoft we had a mandate to be customer focused and very few people knew what it meant. So, every dev, PM, GM and tester would focus on the usual suspects: Usability studies, customer surveys, customer feedback/support, etc.
But I think Jon misses an even bigger point. Whenever you talk about customer you have to define "what a customer is". Let me be clear, is Kevin talking about "existing customers" or "prospect customers" ("desired customers")?.
The problem with listening to your existing customer base if you are a consumer startup is that you are not listening to the other tens of thousands of people that decided *not* to use your product. Or to the millions of people that are part of your target audience and that are not aware of your product yet.
The big issue with existing early stage consumer startup customers is that they are early adopters (ahead of the curve) and they are using a product that is likely to shift directions significantly over its initial 2-3 years of life. So why on Earth are their opinion so important?
Listening to existing customer base is only worth if you already have a established business and is shipping version 3 or later of your product. Ok, maybe I'm being to radical by saying that, but you should discount your existing customer feedback by 10. And discount voluntary customer feedback (a.k.a. support or feedback emails from customer) by another factor of 10. (Thanks to Dave, our VP of Marketing, to make that clear on my mind)
At Sampa, we pissed off users more than once. Heck, we dropped features that were critical to a huge part of our most avid customers. Why? Because they are not representative of the customer we want our product to have.
I think good product managers will understand and avoid confirmation bias, but great product managers (and marketers) will go beyond that and try to really understand what is the need your product is trying to solve and which persons she should be asking for feedback and suggestions.
I think the key lessons are to not be afraid to drop your entire customer base in favor of a different set of customers. That's what startup is all about, adapting to the market needs.
It has been a while since I wrote on this blog. I actually see a correlation by the quality of the blog posts and the length of time between blog posts.
Anyway, I have a lot to share and I was nearly finished adding support for Google Ad Manager for Sampa to control its Ad inventory (BTW, Wetpaint HTML is a better reference than the Ad Manager help) when... I've got a baby!
So, I've had about 2 hours of sleep from Monday to Tuesday and about 5 hours from Tuesday to Wednesday and I expect to have very little time to do any kind of productive coding, emailing, blogging, thinking.
One of the most interesting aspects of Agile development is to not build things that you won't use now or over-engineer a component because "we might need this in the future". That is a wonderful thing for developers and it does cut a lot of complexity and time to deliver the feature, by consequence making it less buggy.
But what about the business/marketing sides of things?
I've been thinking a lot in a new way of building features and I'm giving it the name "organic feature". This is not something we've been practicing at Sampa frequently, but I'm starting to think we should.
Organic Features have two important aspects to it:
You write down or sketch the minimum set of functionality a feature must have to add any value.
You implement the minimum set before you start thinking about the additional elements.
Organic Features have two big DONTs:
You don't start by thinking of all the corner cases and how you can address all of those.
You don't overspend time creating a UI mockup without having implemented the minimum set first
Now, you don't ship the feature after you implemented the minimum set. That's the bar to make sure the core functionality is working, but it still doesn't mean it addresses basic scenarios of your customer. Here comes the "organic" part: You start adding to that base of features after getting the initial feedback from internal people on what they think. The goal is to add a little bit every day and at one point you have the feeling the feature is done and ready for customers.
After you ship the feature, you'll still need a few more iterations to fix core scenarios that were missed, to fix assumptions the team made about the UX or terminology that is getting users confused, and, of course, to fix bugs.
I'm my opinion, Organic Features are the opposite of "Spec'd Features". Spec'd features are built from the inside out, usually one or more person thinks through what it should do, what customers want, what the UI limitations are and they try to be as comprehensive as possible, since the deliverable of this work is a complete "spec".
The core issue here is that a "spec" might write one line that converts into thousands of lines of complex code, or have a three pages to describe something that will take just a dozen or so lines of code. Using the organic feature strategy, it makes it easy for all the people involved to understand the cost/benefit of building the functionality, and as the feature gets closer to complete, more initial complex ideas may become trivial to add or integrate.
This is just a first essay on this topic and I still have a lot to think about this, but think of Organic Feature building as a way to get rid of specs and prototyping.
If you look back at the Sampa sign up form, it has been through 4 or 5 different versions. At one point we asked you about 15 questions. Then we worked with one local UX expert to simplify a bit, then we worked with a Portland-based UX firm to simplify it even more and we had just 8 inputs:
Name
Email
Confirmation of email
Password
Confirmation of password
Agree to Terms of use
Web address
CAPTCHA
After reading the book "Web Form Design Fillin in the Blanks" (by Luke Wroblewski) over the 4th of July, I decided to take a closer look at our sign up form again.
I am always afraid of making any change to our sign up pipeline since we have such fantastic conversion rates that is easy to assume something, make a change and it to backfire.
Well, there was at least one change I've made that was a no-brainer. The Terms of Use checkbox wasn't checked by default and I changed that.
But that's not the interesting part. On the book, Luke mentions that a lot of the things we ask on forms are limitations of the application itself and that it doesn't add value to the customer ("inside out").
You can clearly see some of that on Sampa. Why do we ask twice for your email? Why do we ask twice for your password? Why do we need your name? Why do we need CAPTCHA?
We have good answers for all of the above, and we A/B tested several scenarios over the last 2 years to know that we are close to the right combination that yields maximum conversion and retention. But one piece was never tested and it was off: CAPTCHA.
Why do we need CAPTCHA? Like any other free web service that you sign up to (Hotmail, GMail, Ticket Master, Blogger, etc.) CAPTCHA is necessary to prevent automated bots from creating hundreds or thousands of fake accounts, either for Spam or Link Farm. So it's a necessary evil that good people have to go through so we can keep the bad people out, or is it?
Well, last Monday at 5:13 PM we removed CAPTCHA from Sampa. It wasn't easy and clean, but we created a set of tests and rules that will make us not display a CAPTCHA about 99% of the time. I can't really disclose the tests we make since that's the secret you want to keep out of the hands of bot creators.
The result: 9.2% improvement on our conversion rate!
The entire team is just shocked that such a huge percentage of users wanted to sign up to Sampa and either didn't pass the CAPTCHA (less likely) or found the form more intimidating with a CAPTCHA (more likely). The third explanation which we've been talking about is that with less vertical space, the "Continue" button is above the fold more often and give users a better sense of how short this form is.
When I started Sampa, I thought that most content would be traditional page GET/POST. But then I went back and checked a family tree that I did for my personal site in 2000 that used AJAX. It made sense to use that technology on Sampa and I went overboard. I created my own AJAX framework (in 2005 there wasn't anything solid that I could use) and used AJAX everywhere on the system.
Later AJAX started to become a pain, because a page after being loaded required 3 or 4 AJAX calls to get the additional content. Bad design for the user. The good part is that Sampa used a combination of Frames that allowed us to cache content on the browser, so the AJAX calls to the server were minimized.
From a development standpoint, AJAX is a pain because it requires you to parse the returning XML and do something with it, usually generate some HTML or data structure. This is where AJAH and JSON come in hand.
If you need a piece of HTML to sitck on the middle of the page, you can generate that HTML on the server and send it on an AJAH call. Once you get that is just a matter of setting the innerHTML on an element.
JSON does the same thing, but for data structures and its data in Javascript. Get a JSON response, eval-it, and you have data and 'classes' ready for use, instead of parsing the XML and putting into a data structure.
So, of the 4 technologies above (in-page, AJAX, AJAH, JSON) which one should you be using on your web-based service? All of them! Each one solves a different problem and they need to be used in combination.
This is my non-comprehensive list of tips on those technologies:
in-page: Use that to minimize server calls when the page is first loaded. The same way you should have few CSS, JS and Images file on a page, you should try not to make any JSON, AJAX or AJAH call once the page is loaded at the first time. Everything should be embedded on the HTML you send to the user.
AJAX: Great to take action on the server ("delete this record") without needing to refresh the page, or when you need pagination ("contacts 1-50 of 1750").
AJAH: When the HTML generated is smaller (or faster) than sending an AJAX response and creating the HTML in Javascript. It's also good because you can keep all the HTML generation routines on the server. Like AJAX, you should only use it when you can't have the content embeded on the page directly on the first page request to the server.
JSON: When the results of an AJAX call will be parsed into a data structure, you probably should consider JSON. Size of the response and parsing time are important considerations. Remember "eval" can be very very very very (add 17 more 'very') expensive at runtime. You don't want your user's browser freezing every time it clicks on something.
I'm a big advocate of using 1 or 2 letters field names. Instead of "Username" just use "n", and that goes both to JSON and AJAX. Put the comment on the code to what it means, but save a lot on response size.
It has been just a few days, but Dave Sampson is already making his mark on Sampa as VP of Marketing. Dave is a convert. He started as a techie and moved into marketing, which is just the kind of person we were looking for.
The VP of Marketing at Sampa was the position that was open the longest, probably since I started Sampa in 2005.
You can read more about him on our Leadership page, on LinkedIn or watch one of his lecturers at the University of Washington where he teaches Marketing on the Software Product Management Certificate program.
We plan on shipping a billing system for Sampa some time between now and the end of times. I've never done this before and as far as I know there is a lot of little details.
I'm looking to borrow a developer's brain that has done a billing system for their startup recently. Anyone is interested in coffee or lunch (I pay) to tell me about the dirty side of building a billing system?
Sorry for being picky about it, but I'm not interested in business people or program managers. I really want a developer that got his/her hands dirty defining the schema, doing the API, testing it, etc.
Also, Sampa is not e-commerce type of billing (one time transaction). We (will) have a subscription model, so I care about startups that have similar models.
I'm trying to hunt down a problem where some people are complaining that some email messages sent to me are bouncing. If you sent me an email on the last 3 days and it bounced, would you mind forwarding the bounced message to mcalbucci@hotmail.com?
Preferably, attach the message to a new message, but if you don't know how to do that just forward me the bounce message.
If you want to go one step further, send me an email with the subject "Email Test" and I'll reply with "got it". If you get a bounce send it to me, if you don't get a reply in a couple of hours send a message to mcalbucci@hotmail.com.
I'm the Founder & CTO of Sampa (site builder/blogging service). I was born in Brazil, where I graduated in Computer Science. Moved to the US in 1998 to work for Microsoft and there I worked for 7 years (Exchange and MSN Search). In 2004 I decided to do my own thing and left to start Sampa. Besides my new company, I keep myself busy with my new son which takes most of my non-working time. Once I have a few minutes to spare I read, cook, do video editing, take pictures and hang out with friends.
Subscribe to this Site
.