If you're lucky the first real programming job you get will involve just that programming. However, for the rest of us, it is more likely you'll have to learn how to play the corporate cubicle culture game.Just so you know I'm not just making this stuff up I've spent about 10 months as a full time entry level developer and know what its like to go from a code monkey to a player in the game. I'll get more into what the hell all of that means later. I've also spent more than a year and a half, working as an intern, so I've seen this from a lot of angles. So let's go over the basic view of the general types of coders/developers/other that you should encounter in your travels in the software development world.
The Intern(s)
If you were able to make it through the unusual circumstances that allowed to be brought on as an intern in a major corporation. Congrats you're through the hard part. These people normally get in through various methods but usually are due to one of two reasons they know someone or they're really good at pitching themselves. Sorry to disappoint, this is on position where you're skill level is actually secondary. So the quality of an intern varies greatly, the actual staff knows this, which means for your first couple of assignments you'll be under the eye. The nice thing about this position is that you get to take part in the process without really being accountable for anything. If you are trying to get that job offer, this the the best place to start, if you can impress people here you're almost guaranteed a cubicle spot. I could talk a bit more about how getting an internship makes the post degree job search that much easier but enough has been said about the subject, so I'll just let it go at that.
The Entry Level Software Engineer/Developer (Code Monkey/Grunt)
This varies on the company, but from what I've experienced and what I've heard about other peoples experiences, but in general you walk into the position with little to no idea what you're getting yourself into.Before I get into the cliches of the job here is a brief description of the other cast of characters. Most of the time you're going to be apart of a software group that always has the following people the manager (Systems level) meaning they may not know much about software but they may know engineering well enough to fight the good fights for you. The software leads whether your aware of it or not these people are your actual bosses (if they're good they'll be your first line of defense when dealing with other groups and higher ups), you'll probably report to them often. The veterans, these guys (sorry to be sexist here but most of the time it will be a male) have normally been through a couple of different big projects. They'll probably be your mentors so to speak, they won't hold your hand since more often than not they've got a lot on their plate and they're just there to make sure you don't run out screaming the first few weeks. Normally they will have a lot of good project knowledge and will know their specialties like the back of their hands. However, this is normally where they stop, most of the time they won't be up on the latest and greatest APIs but then again they probably don't need them. The rest of the team is the everything in between, I'd get into more detail but even I'm starting to glaze over the thought so I'll spare you. Your job will be pretty straightforward otherwise, code to specification, verify and test code, follow process, write reports (haven't come across the TPS report yet) this also means you'll probably be kind of bored of it after the first month or so. However, you'll almost always be working with a group, meaning you probably won't get your own projects (which is where all the fun is) unless they've got some major confidence in your abilities.
This post is getting a bit long and I've got some friends waiting at the bar for me, so I'll continue this tomorrow.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment