macOS Is anyone able to tell me what skills you expect from an entry level programmer?

[chrono1081]

Hi guys,

I finally got my resume done professionally and received the rough draft today. It looks good so far and I will be using it to apply for an entry level programming position, preferably in C++ or Objective-C since they are the languages I am most familiar with (although I can learn any language).

This begs the question on what type of stuff are entry level programmers expected to know? I understand this can vary greatly depending on the type of applications a person would be working on but I was wondering if anyone would give me a rough guideline or let me know what you had to know before starting a programming job. I'm trying to gauge whether I should job hunt immediately (I graduate in October) or if I should spend more time beefing up my skills.

The last thing I want to do is get called to do a programming test, find out I don't know as much as I thought I knew, and lose any future opportunity with the company I applied to.

I know its an almost impossible question to answer but if anyone can send any guidelines or suggestions my way I would greatly appreciate it One thing I do want to mention though is I practice new programming concepts daily and never stop learning it. (As you all may have noticed from other posts I am currently learning OpenGL). I'm definitely not one of the people who stop learning as soon as they get out of school and I hope that type of attitude will help me land a job.

EDIT: I've also been looking at positions but they just say things like "C++ knowledge" but C++ is pretty broad and although I'm familiar and use many aspects of it I'm sure there are still plenty of things I don't know.

 

[Sander]

Don't worry about the tests. If you're fresh from school, chances are you'll score better on some of them than someone who's been in the industry for a while. For some reason, many interviewers try to measure "knowledge" by asking you to implement a doubly-linked list or a quicksort algorithm. In fact, if I co-interview someone and he gets asked this question, I silently hope they'll just say "std::list" and "std::sort". I'd *much* rather have someone on my team ask me "I am surprised by the performance of this sort library, can you help me check whether I picked the right one for this situation?" than "I implemented my own quicksort in SSE2 but it sometimes crashes if the original list has an odd number of elements, can you take a look at it?"

When interviewing, I'm not only looking for "the guy who can help finish this particular project", but also for "the guy who will be my next collegue and with whom I will be spending a good part of my time with for the next few years". So I'm looking for enthusiasm and drive. Show me a project you've worked on. Which part sucked, and why? Which part are you proud of, and why? I don't particularly care whether this project was a school assignment, I'm looking for the stars in your eyes when you talk about it.

(Disclaimer: I live in The Netherlands, and it's quite common here to be offered an unlimited contract right from the get-go here, and people aren't easily fired. So it pays off to make sure you hire the right guy.)

 

[Hansr]

Hi guys,

I finally got my resume done professionally and received the rough draft today. It looks good so far and I will be using it to apply for an entry level programming position, preferably in C++ or Objective-C since they are the languages I am most familiar with (although I can learn any language).

Do you know any functional programming or a prototyping language as well?

This begs the question on what type of stuff are entry level programmers expected to know?

Not a lot to be honest. They're mostly useless and need to unlearn a lot of the crap they get fed in school. If you want to get a good job have a real project out there, preferably open source or at least work on an open source project if you don't have a project of your own. I wouldn't hire anyone who hasn't worked on a real project. If they haven't they'll have too much to learn to be useful right away and they also lack the initiative to be a valuable asset.

I'm trying to gauge whether I should job hunt immediately (I graduate in October) or if I should spend more time beefing up my skills.

Just start right away, all experience at interviewing is good experience. I interviewed in Feb/March for my first real job out of uni and I finished in uni Sept. It's better to just land it early and focus on good grades.

The last thing I want to do is get called to do a programming test, find out I don't know as much as I thought I knew, and lose any future opportunity with the company I applied to.

That's not how the world works. If you can make an attempt at the problem and come up with a logical "plan of attack" that's generally acceptable if you can't code the thing with the perfect syntax. You may not ace the interview that time but if you come off as a good programmer and a nice guy whoever is interviewing you will make sure to get you on the team; even if it's in a different role.

Also a programmer with N years experience is a completely different beast when compared to a programmer with (N+1) years experience.

EDIT: I've also been looking at positions but they just say things like "C++ knowledge" but C++ is pretty broad and although I'm familiar and use many aspects of it I'm sure there are still plenty of things I don't know.

Focus on exception safety, templates, algorithms, threads and of course STL and Boost.


Disclaimer: I don't work in the software industry but in quant finance however the same principles govern the coding aspect in both.

 

[whooleytoo]

(Sorry if this advice is too vague but..) don't focus just on "knowledge". No one expects an entry level programmer to know everything, and even if you did much of it could be outdated in a few years.

Show you're enthusiastic, willing to learn. That if you don't know a language/API you can learn it, and if you have a problem you know how to go about fixing it. That you can communicate well, and aren't afraid to ask questions, or even ask for advice.

Here in our company, we work with the assumption we're going to have to spend some time 'hand holding' any entry-level programmers, so enthusiasm and ability to learn quickly are the key.

 

[ShortCutMan]

I applied a for a job as a software engineer around this time last year with my only experience being all hobby work (for around 5 years) and some small amount of formal education in the first 2 years of an electrical engineering degree (which I never finished, nor did I finish university).

I ended up getting the first job I was interviewed for, I think it was because I showed a lot of enthusiasm. My advice to you would be to build up your language skills by just programming as much as you can. Work on a project at home. I wouldn't bother with too much advanced stuff since you will probably pick up a lot if you end up working with a decent company. Become familiar with the STL. You don't need to know all the containers off by heart, but be familiar with the library. Know where to get documentation and how to use it generally. Having a look at boost may be useful also. I advise you learn how to use boost smart pointers (I know they are C++0x/TR1 libraries, but this is the most central place for them still), as they can be central to a lot of projects.

There are lots of good books to read, I'd recommended Effective C++ by Scott Meyers, which is really good for people starting out and looking to broaden their skills.

The best advice is to just keep programming lots really.

 

[lee1210]

(although I can learn any language).

This is really the most important thing. Very few people know everything about any single language. Very few people have the exact knowledge they need day 1 on the job. So having a spongey brain that can soak things up fast is way more important than some particular knowledge you already have about a language. That being said, it is important to have a grasp of general algorithms, design patterns, etc. as these apply everywhere and are rarely what people focus on teaching you when you start a job. They are going to focus on showing you the ropes of their application stack, assuming that you can fit this into a rubric of software design that you already have.

-Lee

 

[notjustjay]

This is really the most important thing. Very few people know everything about any single language. Very few people have the exact knowledge they need day 1 on the job. So having a spongey brain that can soak things up fast is way more important than some particular knowledge you already have about a language. That being said, it is important to have a grasp of general algorithms, design patterns, etc. as these apply everywhere and are rarely what people focus on teaching you when you start a job. They are going to focus on showing you the ropes of their application stack, assuming that you can fit this into a rubric of software design that you already have.

You will likely learn many languages over the course of a programming career. In high school I used BASIC and Pascal, and taught myself C on the side. In university we did C++ and Java and a bit of x86 assembly. Although the jobs I have taken were primarily C++, I have also written code in Python and Ada. Knowing "how to learn" is a key skill ("how to find what you need on Google" is another key skill).

The key difference I found between programming projects at school and the "real world" were the size and scope. All of my programming projects were small (less than a few thousand lines) with most of the code being written from scratch either by myself or in small teams. Maybe a couple dozen classes and/or code files, generally all in the same folder. It's not hard to get a grasp of everything in your head at once.

The projects I work on now consist of roughly 500,000 lines of code, in hundreds of files, worked on by dozens of developers. I've been here for years and while I've become an expert on some areas of code, there are huge chunks of code I have never seen or know how they work... but I could get called on to fix a bug at any time. So, skills I needed to pick up quickly:
- how to navigate through unfamiliar code (a good IDE helps a lot!)
- how to debug code using a debugger, breakpoints, or just plain old fashioned "the value of X is now ___" print statements where debugging isn't practical
- multi-threaded software concepts: tasks/threads, queues, events, locks, interactions
- how to use source control
- how to do effective code peer reviews
- how to refactor small chunks of code without breaking bigger ones

There are also non-programming-related issues such as:
- knowing when and how to ask for help
- knowing when and how to make suggestions for improvements (yes, you've been taught in school that X is the correct way... but the company's been doing Y for years. Do you just go shut up and go with it?)
- learning all about the application domain (if you're coding a financial application, you'll need to learn all about banking and finances)
- how to work with and get along with various types of people
- how to write technical documents that are clear and concise

But if I had to pick out a few key skills:
- easygoing, enthusiastic personality that plays well with others
- willing to learn LOTS and apply old skills to new areas
- knows how to Google to find things
- has a solid programming style (easy to read, well documented code) that doesn't get compromised by time working in "sloppy" existing code
- solid documentation skills

 

[firewood]

I look for problem solving skills, and a resume that lists projects that might have involved some real problem solving. So pick projects for your CV that an interviewer might think required real problem solving skills, and not just hours or LOC of drudge work.

I look up generic software puzzle questions on the web, and then change them so that it's a problem to figure out what I've changed and how to change the stock solution. You'd be surprised at how many people can't listen, and can get quickly walked out the door for spitting out memorized answers that are completely wrong.

Details are important. Almost everybody can pass a survey course on language X. Tell me what's wrong with your favorite language and it's implementation.

 

[SidBala]

I have been a ton of these internship and entry-level software interviews. They are all the same, for most part.

The common thing they are looking at the entry-level is solid fundamentals in computer science. The reason why companies are vague about things like "C++ knowledge" is because they expect you to know you CS fundamentals well but be able to learn the missing C++ knowledge on the job. Some companies will hire you even if you don't know the programming language they use, provided that you demonstrate that you will be able to learn it very quickly.

Projects done in your own time imo, are the single most important thing for an entry-level fresh out of college resume. Every single candidate would have gone through the same computer science program. Projects are what will set you apart from every other candidate. Having tons of these is guaranteed to get you an interview.

You should definitely spend a month or two preparing for the interviews if you want to make it into big companies (Apple, Microsoft, Google, etc). It is extremely competitive for these companies. Candidates are first weeded out by non-technical recruiters looking at you resume. Once the recruiter thinks you are suitable, you will be called for multiple face to face or phone interviews with the technical people. Smaller companies, your resume will be looked at directly by the technical people. And there, there is usually only one interview.

If you get called for an interview, Prepare for the basics. This is where they really test your knowledge for themselves. All the big words like "motivated, enthusiastic", etc on your resume will not help you if you don't do the technical interview well. All software company interviews are surprisingly similar. They mostly focus on data structures and very little on a particular language. They certainly do not ask you about language syntax. This is unless if the job description specifically requires it. You can be sure that you will be asked about trees, linked lists, arrays, sorts, strings etc. You should also be able to perform complexity analysis on these. If you want to be sure of getting the job, these should be like on the back of your hand before you go in for the interview. Traversing a tree, or reversing a list- things like that you should be able to answer in your sleep.

You will be most likely asked to solve a problem on a whiteboard. Ideally, they want you to be able to think of the solution on the spot. But that never works. It is better if you came across the problem or a similar one before and have a solution in mind. Then, you can pretend you are figuring out the solution on the spot. Even simple problems, like the list reversal, are surprisingly difficult when you are in the interview situation with only a whiteboard and no debugger or ide. And remember to do these in pseudocode so there can't be any syntax errors.

I would definitely recommend spending at least a month on preparation and then hitting the big companies. You should also apply for the smaller companies before that to get a feel for the interviews. After you attend a few, you will realize that the pool of questions they can ask is quite small, and you would know how to answer all of them.

 

[chrono1081]

Do you know any functional programming or a prototyping language as well?

No I do not. The only one that I use that could be considered a prototyping language would be Lua. I use it daily and am using it on one of my iPhone game project right now. I haven't used any functional programming languages however.

Not a lot to be honest. They're mostly useless and need to unlearn a lot of the crap they get fed in school. If you want to get a good job have a real project out there, preferably open source or at least work on an open source project if you don't have a project of your own. I wouldn't hire anyone who hasn't worked on a real project. If they haven't they'll have too much to learn to be useful right away and they also lack the initiative to be a valuable asset.

This is where I will run into problems. The only project I have on my resume is a game engine we built in class. I actually blame this on my school (that is not a cop-out believe it or not) because they hammer us with so much junk work that its almost impossible to find time to make a project. Don't get me wrong I work on projects on the side as often as I can (I am working on an iOS game at the moment) but when you have 350+ pages of reading a week, roughly two 15+ page papers due (per week), programming assignments + documentation, project management assignments + documentation, two tests, and work its really hard to get the necessary amount of time. (Thats seriously my schedule each week and I only have two classes). I do work at it though, and next semester I will have 8 weeks of virtually nothing to do but sit and work on my project.

I really wish my school would cut some of the garbage work, like the 15+ page papers out and cut the reading in half and give us more time to work on project, but no worries. I didn't go to college to learn, I am quite capable of that on my own (college actually gets in my way of learning at this point), I went for a piece of paper to show I stuck with a formal education for four years.

Focus on exception safety, templates, algorithms, threads and of course STL and Boost.

This is where I need more practice. I know how to use exception handling and templates, but I rarely use them and have to reference them for the syntax. I'm also not very experienced in STL (I've used it, but I mostly make games and STL is often not used due to speed) and I have never used Boost although I am aware of what it is. I will have to take a look at these as well.

(Sorry if this advice is too vague but..) don't focus just on "knowledge". No one expects an entry level programmer to know everything, and even if you did much of it could be outdated in a few years.

Show you're enthusiastic, willing to learn. That if you don't know a language/API you can learn it, and if you have a problem you know how to go about fixing it. That you can communicate well, and aren't afraid to ask questions, or even ask for advice.

Here in our company, we work with the assumption we're going to have to spend some time 'hand holding' any entry-level programmers, so enthusiasm and ability to learn quickly are the key.

This is most certainly my strongest suit. I love to learn and I will learn and will teach myself anything I want to learn. For example in one of my classes I learned Maya and enough about Maya to make a short 3D animated film in four weeks. (Omg was that rough! But fun!). I also have my nose in a book daily and have a daily "learning goal" that I have to achieve before going to bed each night. I also have plenty of learning resources (books, subscriptions to Lynda.com and DigitalTutors, etc).

I applied a for a job as a software engineer around this time last year with my only experience being all hobby work (for around 5 years) and some small amount of formal education in the first 2 years of an electrical engineering degree (which I never finished, nor did I finish university).

I ended up getting the first job I was interviewed for, I think it was because I showed a lot of enthusiasm. My advice to you would be to build up your language skills by just programming as much as you can. Work on a project at home. I wouldn't bother with too much advanced stuff since you will probably pick up a lot if you end up working with a decent company. Become familiar with the STL. You don't need to know all the containers off by heart, but be familiar with the library. Know where to get documentation and how to use it generally. Having a look at boost may be useful also. I advise you learn how to use boost smart pointers (I know they are C++0x/TR1 libraries, but this is the most central place for them still), as they can be central to a lot of projects.

There are lots of good books to read, I'd recommended Effective C++ by Scott Meyers, which is really good for people starting out and looking to broaden their skills.

The best advice is to just keep programming lots really.

Effective C++ is on my list of to read books, its actually next in line after Accellerated C++ (its boring since I know a lot of this stuff but I still learn new tricks from it so its worth it). Also I am aware of smart pointers but never used them. I'll add those to my list of learn-ables.

This is really the most important thing. Very few people know everything about any single language. Very few people have the exact knowledge they need day 1 on the job. So having a spongey brain that can soak things up fast is way more important than some particular knowledge you already have about a language. That being said, it is important to have a grasp of general algorithms, design patterns, etc. as these apply everywhere and are rarely what people focus on teaching you when you start a job. They are going to focus on showing you the ropes of their application stack, assuming that you can fit this into a rubric of software design that you already have.

-Lee

As mentioned above the ability to learn and spongey brain is definitely a strong suit of mine. I pick up so much information gleaning forums and looking up information and stuff I don't know.

You will likely learn many languages over the course of a programming career. In high school I used BASIC and Pascal, and taught myself C on the side. In university we did C++ and Java and a bit of x86 assembly. Although the jobs I have taken were primarily C++, I have also written code in Python and Ada. Knowing "how to learn" is a key skill ("how to find what you need on Google" is another key skill).

Googling is an excellent skill of mine Seriously I use it all the time if I can't find what I want in the documentation.

- how to navigate through unfamiliar code (a good IDE helps a lot!)
- how to debug code using a debugger, breakpoints, or just plain old fashioned "the value of X is now ___" print statements where debugging isn't practical
- multi-threaded software concepts: tasks/threads, queues, events, locks, interactions
- how to use source control
- how to do effective code peer reviews
- how to refactor small chunks of code without breaking bigger ones

There are also non-programming-related issues such as:
- knowing when and how to ask for help
- knowing when and how to make suggestions for improvements (yes, you've been taught in school that X is the correct way... but the company's been doing Y for years. Do you just go shut up and go with it?)
- learning all about the application domain (if you're coding a financial application, you'll need to learn all about banking and finances)
- how to work with and get along with various types of people
- how to write technical documents that are clear and concise

But if I had to pick out a few key skills:
- easygoing, enthusiastic personality that plays well with others
- willing to learn LOTS and apply old skills to new areas
- knows how to Google to find things
- has a solid programming style (easy to read, well documented code) that doesn't get compromised by time working in "sloppy" existing code
- solid documentation skills

I need practice with muti-threaded concepts. I am aware of them but have never utilized them. I also need practice learning my IDE. I know its very capable but I simply never use the features in it (or am really confused when I see some features). I wish I could find a comprehensive tutorial on something like XCode but I haven't found one yet. I'll keep looking

As for your key skills, I have those down pat. My code is always very clean and well commented, I play nice with others, I know how to document, and I definitely love to learn new things.

I look for problem solving skills, and a resume that lists projects that might have involved some real problem solving. So pick projects for your CV that an interviewer might think required real problem solving skills, and not just hours or LOC of drudge work.

I look up generic software puzzle questions on the web, and then change them so that it's a problem to figure out what I've changed and how to change the stock solution. You'd be surprised at how many people can't listen, and can get quickly walked out the door for spitting out memorized answers that are completely wrong.

Details are important. Almost everybody can pass a survey course on language X. Tell me what's wrong with your favorite language and it's implementation.

I'm pretty good at problem solving (at least I like to think so ). I do it all the time when working on a video game project. Most of my programming is focused around video games (which don't get me wrong, I love) but somewhere in my last 4 years of school I decided I want to make graphical tools for 3D artists instead so I've been trying to focus on regular programming instead. (I kind of wish I'd of went for a regular CS degree but no matter).

They mostly focus on data structures and very little on a particular language. They certainly do not ask you about language syntax. This is unless if the job description specifically requires it. You can be sure that you will be asked about trees, linked lists, arrays, sorts, strings etc. You should also be able to perform complexity analysis on these. If you want to be sure of getting the job, these should be like on the back of your hand before you go in for the interview. Traversing a tree, or reversing a list- things like that you should be able to answer in your sleep.

Thank you for this! Although I am familiar with these and use a few of these data structures quite a bit, I could use more brushing up. I have a giant data structures book (that is EXCELLENT by the way) that I should really read through again. It uses SDL to demonstrate the structures which is a nice touch to be able to see graphically what that do. I'm familiar with SDL too so its easy for me to implement my own.

Don't worry about the tests. If you're fresh from school, chances are you'll score better on some of them than someone who's been in the industry for a while. For some reason, many interviewers try to measure "knowledge" by asking you to implement a doubly-linked list or a quicksort algorithm. In fact, if I co-interview someone and he gets asked this question, I silently hope they'll just say "std::list" and "std::sort". I'd *much* rather have someone on my team ask me "I am surprised by the performance of this sort library, can you help me check whether I picked the right one for this situation?" than "I implemented my own quicksort in SSE2 but it sometimes crashes if the original list has an odd number of elements, can you take a look at it?"

I will definitely need to brush up on my STL and do some research on commonly asked questions.


Thank you all so much for all of the advice My resume came back from the resume writers today and I'm glad it accurately reflects my experience. I still have plenty of things to practice on and will be spending every free second doing so. I graduate in October but I go to school online (basically because my first three years I was working overseas in a war zone so a campus was not an option ) so I can start work at any time. I'd rather make sure I go in prepared and realistically represent myself because in my opinion there would be nothing worse than lying on a resume only to get caught later on. Generally if I land an interview I get hired. I am very good at selling myself (take that as you want) and am always very confident. (I used to be a commissioned salesman what would you expect? )

I'm really glad I took the time to ask questions on here because the answers are much more realistic than when I asked on the Gamedev forums (who basically told me since I went to an online school I'd never have a chance of getting hired anywhere, I guess they don't realize I was doing professional IT work while going to online school )

Anyway if anyone has any other suggestions or tips I would love to hear them. I am off to continue my study regimen now and hopefully get closer to finishing my iOS game so I can slap it on my resume