Hacker News new | past | comments | ask | show | jobs | submit login

From the perspective of someone who worked for a startup as his first real job:

> You are also likely to get some input on the way future engineers are hired and the way your technology team interacts with the business team.

This is true, and not entirely a good thing. I was interviewing new technical hires within a year or two at the organization. I asked stupid nerd questions (if you knew C++ like you claimed, you'd know the ins and outs of this template expansion), instead of important ones like: if you're stuck, will you ask for help, or just silently beat your head against the wall and not have anything to show weeks later?

> An environment that encourages learning and experimentation keeps engineers more motivated than one that stifles its technical talent.

It's also an environment that encourages reinvention of the wheel, especially by younger engineers with little supervision that don't necessarily realize that a particular wheel already exists and is ready to use.

> One of the best skills you can learn if you intend to work for a startup is the ability to figure out things on your own.

This is an existential issue at a startup, and particularly important if you're fresh out of college, because you don't know anything and thus must learn everything. This is both good and bad. On one hand, I learned a lot more in a short time than my friends that went to work for big organizations. On the other hand, I always felt like I never really learned how to do things "right" because a startup is a setting where you don't necessarily have the time to dot your I's and cross your T's.

> It seems like startups move faster and create solutions to difficult problems more efficiently than large companies, but the truth is that they normally have a lower quality threshold than their corporate counterparts.

This rings true to me. It was really a revelation to me when I joined a large organization for the first time. It was a well oiled machine, with roles for everyone and someone whose job it was to do anything that needed to be done. Startups have many advantages, but they're not necessarily productive or efficient places.[1] You can spend a lot of time yak shaving at a startup.

Anyway, I'd do it over again in a heartbeat, but I'm not sure if I'd advise someone to go to a startup straight out of school.[2] Maybe one of those well-funded, well-established ones where they're far enough along to have real internal processes and real management, but I'd save the "three guys in a basement" stuff for later, when you know what you're doing. Again, YMMV.

[1] Of course, I imagine they can be if we're talking about a shop run mostly by highly experienced engineers. But in general, I think big organizations are better at getting more output from less-skilled labor.

[2] At least if you intend to make programming a long-term career. If your intention is to jump over to the business side relatively soon, that advice would change. You'll get far more exposure to the business side at a startup than you will at a large company.




Startups have many advantages, but they're not necessarily productive or efficient places.

So true. There's a lot of ranting and wailing on HN about 'MBA types' and 'managers', but having moved to a large company, I love having project managers. In the wrong company they can descend into ugly hierarchies, but when you get it right a PM can handle talking to other departments/customers and managing expectations, allowing you to focus on actually doing the work. Few startups manage that.


My first job was a start-up, too. The guy we put in as CEO (hey, he managed another company before, and that company was successful) said how we had to hire people who were "self-managing." I later realized this was code for "I suck as a manager." He would bad-mouth "professional management" all the freaking time, but what I saw from him was "amateur management."[1]

And management is hard. I'm not denying that. My previous attempts at management have had poor results. But pretending or hoping you won't need it because you aren't good at it is not the right solution.

[1] The old line about "if you think a professional is expensive, wait until you pay for an amateur" rings especially true here.


Yeah, I used to consider myself a "hands-off" manager. I realized that I really was just a "lazy" manager. There's a happy medium between micro-managing and not doing your job.

Don't get me wrong, I like folks who can be wound up and sent on their way, and they come back with the job done without my intervention. But there's managerial janitor work that always needs to be done. Whether it's helping someone navigate a political landscape, or just making sure they have the equipment necessary to get the job done, there's grunt work. And from my experience, management done right isn't nearly as glamorous as being a trench-working IC coder. If you take a management job so you can be "the boss", I think you're doing it wrong and are going to suck as a manager.


Like so many things, good management > no management > bad management.


This. My current company (consulting agency) has a somewhat startup-like atmosphere, but we currently have 3 full-time devs (including myself) and 5 support staff members (including the founder) - and I can't imagine life without them. They abstract mounds of paperwork, hours of client communication, sales, pretty much everything other than design (also handled by me) and code away from us.

Joel Spolsky has a great article on this: http://www.joelonsoftware.com/articles/DevelopmentAbstractio...

"Management's primary responsibility to create the illusion that a software company can be run by writing code, because that's what programmers do. And while it would be great to have programmers who are also great at sales, graphic design, system administration, and cooking, it's unrealistic. Like teaching a pig to sing, it wastes your time and it annoys the pig."


A good project manager is a very good thing. Of course you also need a defined project for a good project manager to shine.

Also, I hate being put on a project that is poorly defined and I end up having to do the project management stuff. It's not my job, not my strength and not what I was hired to do.


The problem with waiting until later in your career before working for "three guys in a basement" is by the time you get to that stage you are wise enough to realize that:

1) They probably have no earthly clue what they are doing.

2) They won't/can't pay you close to what you're worth.

3) The equity they want to offer you has an expected value that is far, far lower what they think it is and is in no way going to make up for the paycut you will take.

4) They are no smarter and have no better ideas than you so why the heck not just start your own company instead?

I guess my point is, as you get older, you kinda come to the conclusion that working for other people's startups isn't all that it is cracked up to be.


As you get older, it becomes a better idea to be one of the three guys rather than working for them.


I feel like any startup I could found wouldn't be one I'd find interesting to work at. My former boss was a PhD with decades of expertise in his field. Working for him was an experience I couldn't have made happen myself.


I'd also add that as you get older you tend to have more responsibilities like kids or a mortgage, which can be difficult to handle in the unstable world of early stage companies.


I think it's wise to consider a startup job independent of any possible financial windfall. Even if there's no exit, will you be glad to have worked there? Will you develop skills and be exposed to opportunities that you're looking for?

In some ways, this suggests startups are a better choice for people who have worked long enough to know what they're trying to accomplish at the next stage of their career. (I don't doubt that some college grads know this already.)


The C++ snippet is very true.

That's the important thing, it's ok to try to solve it yourself but also to raise a flag. Funny thing, I had a C++ thing I didn't understand and had to ask around (yeah, const_iterator ftw!)


> It's also an environment that encourages reinvention of the wheel, especially by younger engineers with little supervision that don't necessarily realize that a particular wheel already exists and is ready to use.

Even big companies do this with alarming frequency. The best example I can think of is Google reinventing XDR (which was codified in an RFC!) via Protocol Buffers.


XDR has no support for versioning. This is probably the most important features distinguishing PB.


I can't find any details about Protocol Buffers supporting versioning. Can you point me in the right direction?


Or they try to reinvent a plane (with all the complexity) where you only need a bicycle.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: