Marcelo Calbucci

    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.