Career Planning as a Startup Engineer?

As a founder of a software and consulting company in Austin, I'll tell you what I look for in an early stage engineer.

The most important thing I look for in an engineer for a start-up is what I call "alignment". This means that the engineer believes in what we are trying to do, has a commitment to work as hard as I do, and has the personality to persevere through hard times with very little knowledge about what the future may hold. The engineer must also be able to deal with ambiguity, work with little direction, and be very tolerant of the mistakes made by the founder. Many startup founders have no employee management experience, so an ideal engineer is someone who can be tolerant of having a boss that means well but has no idea what he/she is doing.

On the technical side, I value an engineer who is fast and adaptable. Time is at a premium in a startup - most don't have much money, so they need to generate revenue quickly. I'll take an engineer who can develop good quality software quickly over one that can develop great software slowly. A few years later, I may want the latter, but in the startup environment, speed wins. I also want someone who can pick up a new technology quickly. There's no room for religious wars over technology preference - if a customer's environment dictates a certain antiquated technology, I need someone who can learn it and make it work.

Kind of a general question, so I'll give a general answer:

Always be learning.

Sure, this advice applies well to ANY software engineer, but as a STARTUP engineer, bleeding edge technologies are your specific realm. Day-jobby cubicle jockeys can chip away at commodity software with commodity tools for years and make solid living, but the startup engineer needs to intimately understand the Next Big Thing(s) and be able to put them to use bringing new innovation to market for cheaper than ever possible before.

Some examples that are relevant today (for the average, blue-sky startup idea that needs to get to market fast and build incrementally):

• Ruby, Python > .Net, Java
• MySQL, PostgreSQL > Oracle, MSSQL
• NoSQL/schemaless DBs > traditional RDBMS
• Cloud Computing > traditional hosting/computing infrastructure
• StackOverflow > MSDN
• DVCSes like Git, Mercurial > CVS, SVN
• Github, Google Code > SourceForge
• Agile, short iterations > Waterfall, 2-year dev cycles
• etc

But again, that's just the situation as it stands today. In 5 years (maybe 2 years), the left side of this list will be on the right, and the whole point is to know what the new, yet-to-emerge technologies that supplant them on the left will be.

Good luck!

As a software engineer, you can either start a company, or join an existing one. If you want to work in a startup because you want to work in a small company, but don't want to be the founder, then joining a small company is the way to go. If you want the control and responsibility associated with starting a company, then you should aim to start your own company.

As you have said, many of the questions on this site will help you be an entrepreneur... As for joining a startup as an employee, you might need to move to a geographical area with lots of startups. You should join groups, clubs and forums for founders, so that you can meet them when they start looking for people to join their new teams. You need to make sure that the odds that you will be at the right place at the right time is most likely. Make sure that your friends are aware that you are looking to join a startup... Write it in your facebook status, tweet it to the world, and that way people will start giving you offers.

You might even be able to find a founder on this website who is looking for an engineer.

There is an another way to get some precious advice that you can google some expert panel on career stuff or just visit some of these for more help like http://www.lifestylerescue.com

I disagree about the tools being used, the bleeding edge is not always the best. Stackoverflow was built using .Net and MSSQL and it was a startup. Developers should use the tools they know the best and not keep looking for the next big thing. If you are not careful you will get into the cycle of constantly changing your platform just because it is no longer the newest thing. Plus the documentation of some of those bleeding edge tools is very spotty, you could waste lots of time on a problem and never find the answer. In my opinion, find what works and use it.