Marcelo Calbucci

 

    I can't say to much and give out the farm, but what is the opposite of social network?

 

    Think how can you share in a non-social network way, but with the benefits of a social network... Did I get you curious?

 

    Step 1: Vote for our panel at the SXSW

    Step 2: Attend SXSW

 

 

 

    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.

    The problem really occurred when they started using customer touch points to justify pet features. Kevin Merritt Jon Byrum from blist does a good job of describing "confirmation bias" and why it's dangerous.

    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.