I suspect you're thinking of a product that would support a business -- the post you're responding to mentions a "subsystem".

This is only a few steps beyond what anyone who completes a CS degree does at least two or three times during their coursework. If you take one of your end-of-year projects, do the work to make it actually robust enough for other people to use, and share it with the world (then do a few iterations of "wow, people aren't using this how I thought" and "wow, apparently that wasn't robust at all" and "damn I need real revision control", or even "huh; no one seems to want this at all") -- and fix the things that were wrong with your first attempts -- you're now far more valuable working any part of the process in large project dev than any of your classmates.

Your project doesn't need to be big -- it probably shouldn't be, or you'll never get it out the door -- but scoping it is a lesson in itself that's really valuable to future employers.

This is how I got my first software engineer job, fresh out of undergrad with a major in music; I had developed a set of music theory training drills, put them online (for free) and had already fought my way through a lot of lessons about browser incompatibilities, usability for non-technical users, how to support non-technical users effectively, etc. etc..

There was no way in hell I was ready to start a business of my own, at that point, and I was eager to work with more experienced developers -- I wanted to learn better ways to solve the problems I was struggling with -- so in seeking a job I wasn't just someone saying "I learned some stuff in school; can you pay me money for it?". I was saying "I already know somewhat what you do here; I want to learn how to do it really well, with you -- will you pay me to do that?"

Exactly. I really don't think that what we ask for should be hard to find, but experience proves otherwise.

It is interesting that they are looking for someone who can complete an entire product cycle. Maybe looking for flexibility, if they are a consulting shop? Or seniority--someone who can do all that has been around the block? Or maybe they are such a small shop they can't afford specialists?

I have been in this full lifecycle role almost my entire career, often as a consultant, and it has benefits and downsides. You are always learning something new and have a wide view of the software world, as well as the ability to really dig into new toes of problems. But sometimes you feel a mile wide and an inch deep.

Nope, I work for a multibillion dollar company. We don't have separate roles like "architect," "business analyst"," "programmer," etc. We hire people who can be given a requirement, and then trusted to get it fully implemented. In the beginning, especially if you're fresh out of school, you may be given a simple design and told "code this," but that phase doesn't last very long.

> Why would a person with the skill set of an entire team want to work for a company, rather than starting their own?

I've completed an entire product cycle by myself, more than once, but still work for a company.

Working for a company means I don't have to go out and find the customers, I don't have to do sales and marketing, and I don't have to do the hiring, firing, and day-to-day management of employees. Basically, there's more to running a company than the parts of a product cycle, and insofar as I might be capable of doing all of those other things, I don't enjoy it as much as focusing on solving problems.