What is required knowledge when applying for an entry level or junior programmer position? (think "first job")

Question

In a previous question, I explained my current predicament and general dislike of my job. A large part of the issue (other than nickel and diming of time, down to the quarter hour, with no place to represent coffee/washroom breaks) is that I took the job for financial reasons and hate the technology (COBOL and other legacy utils).

I've decided that I need to brush up on my skills and find a job in newer technologies (preferably C# development, but I'm open to alternatives) as an entry-level/junior developer - hopefully somewhere understanding with great mentoring potential.

To this end, I've begun reading Essential C# 3.0 and Code Complete while on another brief stress leave. I've only got a couple weeks, but I'm hoping I can get to a point where I feel comfortable applying somewhere else by the time I go back to work.

According to the accepted answer to this question, an entry-level developer is:

Straight out of education or off the street; shows programming ability, but lacks language\business experience.

I've been very slack in the last couple years with regard to getting/staying current, largely due to fatigue at the end of a work day (i.e. "I just want to relax and not think about programming" - though I do read a lot of coding blogs, stackoverflow, etc.). College was sort of a joke, with lots of classes dedicated to "learning language x" - syntax over substance.

To make a needlessly long question short:

• What do you consider essential knowledge when applying for an entry-level position?
• What sort of questions do you think would be asked in an interview situation?
• Where should I focus my studies?

I'm aware that most of my "real" learning will occur on the job with mentoring, etc. but I want to be reasonably sure I can get and hold the job I need to get me the rest of the way.

Thanks for reading such a long question, and for any help you can provide!

Answer 1

I'm in a junior programmer position myself . I've been hired 8 months ago , and I currently work on Java/C++ .

Essential knowledge

• knowing some data structures ( queue , stack , hash table , list ) and how to make use of them
• knowing some algorithms
• knowing your way around google
• VERY IMPORTANT : learn how to use a debugger !

Questions you will be asked in a programming interview :

• questions related to OOP ( polymorphism )
• some design patterns ( 2 or 3 you like )

Other tips:

• learn regular expressions
• learn a scripting language ( you will benefit a great deal from this )
• get yourself a cookbook for your language of choice . Your productivity will increase a lot .
• try to have fun , no mather how much your job will suck :) ( if you succeed in doing this , tell me how )

Good luck !

Answer 2

The specific knowledge (languages, etc) we require from grad developers is specific to the role they're going to be doing, so it's a bit hard to answer the question generally for technical things.

When I'm interviewing grads the things I look for:

• ability to learn and think on their feet (since that's what they'll be doing for at least the first 6 months in the job)
• not too self-important and demanding. Sadly that's a real problem these days -- grad developers who come in and think they're the best thing since sliced bread, and expect that they'll be given the most interesting assignments and be able to lead teams on Day 1.

Your academic knowledge is only half the picture, your on the job knowledge is essentially zero and your first 6 months will be spent gaining that. I look for grads who I think are prepared to learn how be part of a team and part of a business.

Answer 3

Don't beat yourself up. You may not have experience of the latest and greatest, but there may be other places that aren't like Initech that would appreciate the skills you have now. I'd say that even irrelevant experience can be useful, since any workplace experience is better than none. Just try not to bad-mouth your current employer when the interviewer asks why you want to work for a new company.

Plus, you show you want to learn, that's always good. I'd imagine a good interviewer will ask what books you're reading (or have read recently) and you can truthfully say you are reading two good ones right now.

If you have time, as a personal project try to produce some software that shows what you are learning to an interviewer. I just wish I had time and the ideas.

Answer 4

Having seen the crop of candidates out there, I've learned to have deceptively simple requirements:

• Basic programming skills that can be applied regardless of underlying technology or domain. A basic understanding of data structures, algorithms and OOP.

A lot of candidates can't actually program. I need to know you can come across a new problem and apply your existing skills to it. We run a business development shop, and always ask candidates to implement a simple game (e.g. tic-tac-toe). It doesn't matter that it works, just that they demonstrate some inkling of insight into how they should solve the problem. You'd be amazed how many experienced business programmers have absolutely nothing after four hours, no code, and no ideas.

• Not being a prima donna.

If you're a junior, you have to learn to be part of the team, not try to go around the team. It's ok to ask questions and make suggestions, but you should accept the way of working even if you don't agree with it.

• Most importantly: the ability and desire to learn.

I've seen people who were incapable, and people who just didn't want to. If you don't voluntarily stay up with technological evolutions, your value over time only decreases instead of increasing.

Answer 5

My advise: Don't sell yourself too cheap.

You want a change, that's ok. You want to learn soemthing new, that's good. You already have experience (even though not in C# projects), that's even better.

In my book, you would already be over qualified for the position of a junior programmer, but I would be happy to hire you for that salary ;-)

My basic requirements:

• Understanding of a (compiling) programming langugae
• Understanding of how to debug
• Understanding of a scripting language
• Understanding of concepts like algorithm, OO, design pattern
• Understanding that there is more to SW development than just programming: deployment, training users, helpdesk activity etc (Ok, maybe that is already for a not so junior any more programmer)

Answer 6

I went back and read the previous question you linked to, and I am more concerned about these "Stress leaves". I think you need to get your mental health in order before you attempt a change of career. Any programming gig you take will require long hours, deadlines, and even code you don't enjoy maintaining. If there is a holy grail of a coding job out there that requires no stress, then I'd be very interested in finding out what it is.

We are somewhat expensive employees, thus, there will always be demands put upon us to finish things in a timely manner. Now, not everyplace will require you to skip bathroom/coffee breaks, but almost every place will require you to bill your time to assigned projects, so you will be keeping track of what you are doing every day, and will be expected to do it. I have never seen a time-keeping system that required me to code time to bathroom/coffee breaks, and frankly, would be more concerned with one that did than one that didn't.

So, I suppose to at least attempt an answer to your question, in your case it sounds like you have the technical abilities, you have the intellectual abilities, now you just need to learn how to handle stress and a workload that may sometimes be overwhelming, but necessary.