Entry-Level Tasks
Going into a typical contracted software development studio, what sorts of tasks would such a company want recently-graduated or soon-graduating B.Sc. CompSci majors doing? More specifically, what sorts of things should be highlighted or featured on a resumé?
I'd imagine I should feature the areas and skills where I've focused and where I have much experience, and then go through a more complete point-form listing of where I have enough experience and skill to work in immediately without training.
Any suggestions, or sage advice to pass down?
One hiring pet-peeve is people who seem to imply they have more experience or knowledge than they really do. OTOH, ppl need to be able to list all the things that they have been exposed to.
One thing I used to do with my resume was to use a table layout in word, and then list each job experience in a paragraph, and then next to it, each skill that I used or learned there, listed in order of
expert
C++ ( 10 yrs )
familiar with
Assembler ( 2 yrs )
exposed to
Lisp ( 3 months )
etc.
That way you can list everything that you've done without misleading anyone.
One thing I used to do with my resume was to use a table layout in word, and then list each job experience in a paragraph, and then next to it, each skill that I used or learned there, listed in order of
expert
C++ ( 10 yrs )
familiar with
Assembler ( 2 yrs )
exposed to
Lisp ( 3 months )
etc.
That way you can list everything that you've done without misleading anyone.
I'm with Joel on this one (he likes to hire people who are Smart and Get Things Done), and I emphasize the things I have accomplished. In your case, either a pet project or your senior project would be good examples.
In my expierience most companies want someone who can work self-responsible, fast, task-orientated and is able to find problems and suggestions on his own. If you will work on large projects you should be able to manage smaller teams or at least have good communication skills. You should also have the ability to gather new information and skills on your own. A good understanding of marketing and buisness processes is also often required . The qualification should be at least 2 well known programming languages and also a good understanding of common software-engineering techniques. It's also important for them that you have a well handling of standard software in the specialized field you will work (Compilers, System-tools and managment tools like CVS). It's also very useful to have good writing skills for documenting your work.
Hmm .... I think that's all at the moment :)
Hmm .... I think that's all at the moment :)
All of the advice so far has been great. Here are my two pesos worth:
#1) Have a portfolio of past works.
A good portfolio is 10x more important than good school credentials IMO.
let me repeat that...
A good portfolio is 10x more important than good school credentials IMO.
Nothing a company hates more than a "paper developer" (ie has great credentials, but no experience). I could care less that you went to MIT or Fullsail if you have nothing to show for it. On the other hand I could care less that you didn't go to school if your work is top notch.
In short, a picture is worth a thousand words and a portfolio is worth a thousand resumes.
#2) Play to your strengths.
Typically, you aren't just hired 'carte blance' into a studio...they have hired you as a programmer, or artist, or producer, or whatever. POint is that you should already have an idea of what your strengths are, so play to those. If art is your gig, list all the art schools, art shows, and other experience; if programming is your gig, show them a small program you did (even if it has nothing to do with games); etc.
#3) Show that you have a life.
This one depends on the studio...the smaller the studio, the more they will want you to have personality and get along with everyone else at the company picnic. If it's a larger studio, you are more of a cog and thus the less life you have outside the company, perhaps the better. I tend to think that a good company wants stable employees, not burn-out prone workaholics; thus I think it's a good idea to tell them about your band, or your weekend camping trips, about your family, etc.
#1) Have a portfolio of past works.
A good portfolio is 10x more important than good school credentials IMO.
let me repeat that...
A good portfolio is 10x more important than good school credentials IMO.
Nothing a company hates more than a "paper developer" (ie has great credentials, but no experience). I could care less that you went to MIT or Fullsail if you have nothing to show for it. On the other hand I could care less that you didn't go to school if your work is top notch.
In short, a picture is worth a thousand words and a portfolio is worth a thousand resumes.
#2) Play to your strengths.
Typically, you aren't just hired 'carte blance' into a studio...they have hired you as a programmer, or artist, or producer, or whatever. POint is that you should already have an idea of what your strengths are, so play to those. If art is your gig, list all the art schools, art shows, and other experience; if programming is your gig, show them a small program you did (even if it has nothing to do with games); etc.
#3) Show that you have a life.
This one depends on the studio...the smaller the studio, the more they will want you to have personality and get along with everyone else at the company picnic. If it's a larger studio, you are more of a cog and thus the less life you have outside the company, perhaps the better. I tend to think that a good company wants stable employees, not burn-out prone workaholics; thus I think it's a good idea to tell them about your band, or your weekend camping trips, about your family, etc.
Quote:Original post by Magmai Kai HolmlorI'd add that Getting Things Done is more important (to your boss) than being Smart.
I'm with Joel on this one (he likes to hire people who are Smart and Get Things Done), and I emphasize the things I have accomplished. In your case, either a pet project or your senior project would be good examples.
I started working at at a smallish company four weeks ago (my first full-time job) and I've done a variety of things (mainly development). I'd guess that at a bigger company the typical tasks might be different though.
Make sure that you communicate effectively: let them know that you're smart and learn fast (unless you're not and/or you don't). I'm working in Java, a language which I haven't used since my first year of university (four years ago), and I've been working with stuff that I've never heard of before. I had no portfolio: they hired me because I gave the best answers to their technical questions, I emphasized the fact that I'm a fast learner, and because they got along well with me in the interview.
My old classmates and me graduated last year in software engineering and most of us started working. The tasks each one is doing varies quite a bit.
One started at a software firm of medium size, and he started out doing 3rd line support, digging through source code finding bugs reported by customers.
Another one started working in Philips Medical systems, and as far as I know he's doing full development work and is overloaded with meetings.
I started in a very small company (3 ppl, including boss, the other did production), got handed 4 software projects of poor quality and was told "make something of it".
I graduated at Océ R&D (office printers), and when you enter you are placed in a software development team (usually engineering, last stage of the development) and get handed some relatively simple tasks like making a logger for the project.
So, it varies per company what tasks you will be doing at entry level.
As for resume... I have no idea. I wrote mine quite a while ago, and was told it was too elaborate (describing skills and all). I never could be bothered to rewrite it because I got offered this job.
I guess I will be rewriting it this week because I'm quitting this job. Be aware of small companies I can tell you, and don't think you will get the chance to focus on one project for more that two days. And prepare for the regular "my email doesn't work" requests.
One started at a software firm of medium size, and he started out doing 3rd line support, digging through source code finding bugs reported by customers.
Another one started working in Philips Medical systems, and as far as I know he's doing full development work and is overloaded with meetings.
I started in a very small company (3 ppl, including boss, the other did production), got handed 4 software projects of poor quality and was told "make something of it".
I graduated at Océ R&D (office printers), and when you enter you are placed in a software development team (usually engineering, last stage of the development) and get handed some relatively simple tasks like making a logger for the project.
So, it varies per company what tasks you will be doing at entry level.
As for resume... I have no idea. I wrote mine quite a while ago, and was told it was too elaborate (describing skills and all). I never could be bothered to rewrite it because I got offered this job.
I guess I will be rewriting it this week because I'm quitting this job. Be aware of small companies I can tell you, and don't think you will get the chance to focus on one project for more that two days. And prepare for the regular "my email doesn't work" requests.
Quote:Original post by fastlane69
(snip)
let me repeat that...
A good portfolio is 10x more important than good school credentials IMO.
Nothing a company hates more than a "paper developer" (ie has great credentials, but no experience). I could care less that you went to MIT or Fullsail if you have nothing to show for it. On the other hand I could care less that you didn't go to school if your work is top notch.
In short, a picture is worth a thousand words and a portfolio is worth a thousand resumes.
Of course, a good portfolio is what will make the difference. I still disagree with you for a lot of reasons:
1) Showing code is the easy task. You can take code that you didn't write, use it successfully - because the help file was veru good - and have a good product. I won't trust any applicant until it shows me that it is his code.
2) "paper developpers" don't exist, or are very rare. Who can graduate a BSc without writing a single line of code?
3) ungraduated top-notch guys are rare, very rare.
A sa consequence, IME (yeah, experience is better than opinion [wink]) a resume is still worth a thousant portfolio :)
Regards,
Quote:Original post by fastlane69
(snip)
let me repeat that...
A good portfolio is 10x more important than good school credentials IMO.
Nothing a company hates more than a "paper developer" (ie has great credentials, but no experience). I could care less that you went to MIT or Fullsail if you have nothing to show for it. On the other hand I could care less that you didn't go to school if your work is top notch.
In short, a picture is worth a thousand words and a portfolio is worth a thousand resumes.
I wouldn't hire you because you are obviously inexperienced...
A person without a degree would have to be 10x better than a person with a degree for me to hire them. There are so many things you learn at school other than book knowledge. Also, to get a reputable engineering degree, i.e. from MIT as you put it, you HAVE to be smart...if it were easy, everyone would have a degree from MIT. I also know as a fact that if you gave a MS or PhD from MIT (or somewhere similar) you get paid a TON more.
LMAO...you put MIT and Fullsail in the same sentence :)
Exactly. You can't exactly skate through MIT.
I think the point here is your resume should highlight your projects instead of just being a laundry list of skills that says nothing about what you've actually accomplished. What did you do at school (or in your spare time) that's extraordinary (even if it's just a final project for a really hard class)?
After a lot of iterations, I wound up doing my resume like such:
Project: Magical super-awesome 3D game engine
Environment: C++, OpenGL, GLSL, rigid-body physics, x86 assembler (for optimization)
Beyond the resume, my advice is to know (at least a couple of) the projects on your resume in depth such that you can produce the design for them off the top of your head, and possibly recode a function or two. I choked in my first couple interviews (at big scary corporations) because I couldn't remember any details of my projects.
Also, don't exaggerate too much on the resume. Don't put anything on there you wouldn't be able to answer to in an interview. If you took a hardware class and had to do one simple project in VHDL, don't put that on your resume unless you feel confident enough to answer questions about it.
I think the point here is your resume should highlight your projects instead of just being a laundry list of skills that says nothing about what you've actually accomplished. What did you do at school (or in your spare time) that's extraordinary (even if it's just a final project for a really hard class)?
After a lot of iterations, I wound up doing my resume like such:
Project: Magical super-awesome 3D game engine
Environment: C++, OpenGL, GLSL, rigid-body physics, x86 assembler (for optimization)
Beyond the resume, my advice is to know (at least a couple of) the projects on your resume in depth such that you can produce the design for them off the top of your head, and possibly recode a function or two. I choked in my first couple interviews (at big scary corporations) because I couldn't remember any details of my projects.
Also, don't exaggerate too much on the resume. Don't put anything on there you wouldn't be able to answer to in an interview. If you took a hardware class and had to do one simple project in VHDL, don't put that on your resume unless you feel confident enough to answer questions about it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement