Which skills would you expect and appreciate in a Junior Software Engineer?

Question

I recently finished my Master of Science in Software Engineering, and I am about to start my professional career in a few weeks. My role will be as a Junior Developer for a company which develops software using Java & related technologies (among them Spring and Hibernate). To be honest, I am really excited about what is coming, especially because I want to develop my career as a Java developer. I am also very interested in gaining experience in the field. Additionally, this is going to be my first work experience as a professional developer so I really want to do my best from the very beginning.

I would like to know which skills and abilities, both soft and technical, would be most appreciated in a new professional (Junior Developer) that could be part of your team and in which skills I should focus on to achieve a successful career as a Software Engineer.

Find a gateway drug/activity for when things in the real-world work setting do not work out as you would imagine, but make sure that its effect does not spill into morning. — Job, Feb 15 '11 at 20:37
Since you're a JSWE. Be competent in the languages you said you were competent in. Nothing is more exasperating to hire someone who says they know a language but only learned it in one class. Example: people who list C/C++ on their resume but can't use one or the other (god forbid, can't use either!) — aqua, Feb 16 '11 at 04:40
What happened to the dream of making video games? You "want to develop [your] career as a Java developer", seriously? just kidding, to each his own :) — cambraca, Feb 16 '11 at 05:03

score 61 · Answer 1 · answered Feb 15 '11 at 13:58

61

Here's a quick list off the top of my head:

Follow-through (finish what you start)
Honesty (tell me if you're stuck)
Curiosity (find out better ways to do things)
Open-mindedness (both to criticism and to ideas that aren't yours)
Generosity (share what you learn; train the next generation)

answered Feb 15 '11 at 13:58

Alex Feinman

5,792

1

I agree with all of the listed qualities. If I were asked to mentor such a junior programmer, I would be glad to do so, and it would make my work day much mor eenjoyable. – Adam Crossland Feb 15 '11 at 14:14
3

I think this list pretty much sums it up, the only thing I could possibly add is communication. I have seen so many promising young developers get left behind because they simply didn't want to communication with their team members. Coding alone just doesn't cut it these days, you have to talk to users, team members, and get involved. Also, learn how to write well since you will be doing more of that than you ever thought you would. – Nodey The Node Guy Feb 15 '11 at 15:14
14

+1 Honesty: Learning to say, "I don't understand this." -- first to yourself and then to your colleagues -- is really important. It opens the door to communication and to learning. I've seen too many programmers who allowed their ego to get in the way of expanding their minds. I've been working in this industry for most of 4 decades and I still run into stuff every single day that I don't understand. So I google, I read, I write practice code, and then I have one more skill I can bring to the table. – Peter Rowell Feb 15 '11 at 15:20
On open-mindedness - this particularly includes exceptions to the rule-book. I've failed on this point. Part of experience is learning when to break the rules. Sometimes, forcing everything to fit your ideals just makes everything more complicated. OTOH, not knowing the rule-book at all... – Feb 15 '11 at 15:44
Great list, and not limited to junior developers. Some of those skills are the hardest to learn and the easiest to forget. – Wonko the Sane Feb 15 '11 at 16:32
1

On the Honesty part: What I tell people working for me is to spend a half hour trying to figure it out on your own, then ask me for help or a pointer. If I don't have an immediate answer, bang on it for four hours or so before letting me know it's taking more than that. That's when we start dragging people off of other tasks to help. These days, I would also counsel them to search in, and then ask in Stack Overflow, and google in general, early on in that process. My goal here is to prevent the instant interruption response, which can kill the productivity of the folks around you. – Hack Saw Feb 15 '11 at 23:18
Being willing ask question and learn. Yes I may have been doing this for 20 years to your 2, but if you have a good idea spit it out, you might be right. But even more importantly we might both learn something talking about it! – Zachary K Feb 16 '11 at 12:40

score 50 · Accepted Answer · answered Feb 15 '11 at 14:04

A lot of these are true no matter where you are in your career, but might be especially important for someone who is just starting out.

Listen more than you talk. Learn from what other people are saying.
Be humble. Don't be afraid to share your ideas, but don't assume that you're right and everyone else is wrong. If you see something you think is wrong, ask about it, don't make pronouncements about it.
Keep learning. The foundation from your education is (should be) great, but you have only begun to learn the profession. Learn by doing. I don't think you can really learn unless you are actually practicing what you are learning.
The customer rarely knows what he wants until he sees it. Get used to your requirements changing. Adopt a style of development (if allowed) that gets things in front of the customer quickly to get feedback.
Find people who are good at working with customers and ask them to mentor you in how to develop relationships with them.
Write well-tested, robust code. Getting it done is not the goal; getting it done right is. If you're any good at it, speed will come with time.
Work hard. Don't wait to be asked to do something; look for or ask for things to do.
Own up to your mistakes or your team's mistakes. Don't throw your team members under the bus in front of the customer, but be honest when you have code problems.
You may think that your teammates want you to be a brilliant coder. That would be awesome, but your teammates really want you to be competent and not a jerk. If you're going to be a jerk, you'd better be brilliant.

+1 for "The customer rarely knows what he wants until he sees it..." — FrustratedWithFormsDesigner, Feb 15 '11 at 14:36
+1 for "Keep Learning". That is probably the most important thing I would look for in a junior level programmer — Rachel, Feb 15 '11 at 15:13

score 8 · Answer 3 · answered Feb 15 '11 at 16:06

8

Two things: the willingness to learn and the ability to learn.

answered Feb 15 '11 at 16:06

Dima

11,832

score 4 · Answer 4 · answered Feb 15 '11 at 13:57

Curiousity, enthusiasm, sets a high standard for yourself, willingness to learn, willing to admit they don't know, interest in what the business does and how it affects the work you produce. (All good qualities even if you have 20 years experiences)

Good technical knowledge is great but you have to show how you would apply this knowledge.

Above all, the interviewer has to be able to see you working there making a contribution and wanting to stay. If you are too good, that can put some people off faster than being below average. ;)

JB King · Answer 5 · 2011-02-15T16:21:10.920

Motivation. Do you know how to motivate yourself? Do you know what tactics may work better than others? This is about self-awareness that some people may expect you to know from all the education you've done to have found this out on the side.

Basic testing and debugging skills. Do you know what a unit test is? Do you know a few ways to debug a problem? This isn't about knowing specifically what to do in an environment but rather the general idea of what the most basic tests can be and what strategies to have in looking at a problem.

Communication skills. How precise are you with language? How well can you go from technical to non-technical? Granted this is something to develop, but it is something to note and in some cases save someone that may get themselves in trouble by not understanding the implications of what they claim. How well do you get along with people? Not that this is a strict requirement but if you can have good relationships with fellow co-workers, it can make some jobs a bit easier to handle. Honesty and integrity also fall under this skill group as generally there may be questions about how well do you say what you mean and mean what you say. "Office Space" has lots of examples of poor communication and while the work is fictional, there may have been many scenes that were really close to reality for some people in terms of working in office environments.

Versatility. New people on the team may get a broad set of responsibilities so that if in a small company you may have to set up databases, networks, web servers, and other stuff that is outside of development. Pitching in to help a team meet a deadline would be another example in here.

+1: I'd like to add honesty to the Communication Skills section. If you are completely unfamiliar with something, or if you are stumped on a problem, telling a senior colleague or team leader early can help avoid more serious problems later. — oosterwal, Feb 15 '11 at 16:15

score 3 · Answer 6 · answered Feb 15 '11 at 13:54

3

For me, as a junior developer without any degree, my willingness to work hard and improve myself has greatly helped with my career. Also I noticed that being able to cope with some criticism (positive or not) and being able to follow up on that was appreciated by my superiors.

As for a new environment: I'd advise to just go with the flow for the first week or so. I made the mistake of trying too hard, that was not appreciated.

answered Feb 15 '11 at 13:54

Zsub

221

Yes. Accepting criticism mean asking a lot of follow-up questions to make the 'criticizer' more comfortable. Ask what else could you change to do better. Show the next example with the same issue - have you done better this time? Are you improving? Once everyone really gets comfortable with constructive criticism, the fun begins. Just rmember that your business product folks may not be thinking this way though ;) – Michael Durrant Jan 06 '13 at 15:26

score 3 · Answer 7 · answered Feb 15 '11 at 17:33

I agree with everything that's already been stated, but I want to emphasize that you should never forget these general (and soft) skills in lieu of being a technical expert. You should work on both, but I'd much rather have an intermediate who can communicate what they know then have a master who'd rather work alone.

Also, don't spend too much time with your nose in a book. Books are good, great even, but if you spend most of your time reading and less of your time working, you're not going to get half as much out of those books.

++ Good point, Wes, though I have to wonder. If I ask people these days if they've read such-and-so, the answer is usually - Read? — Mike Dunlavey, Feb 15 '11 at 19:05

score 2 · Answer 8 · answered Feb 15 '11 at 15:17

2

Great answers all. I would only add, from my limited flying experience - you know what they call a pilot's license?

A license to learn.

answered Feb 15 '11 at 15:17

Mike Dunlavey

12,835

score 2 · Answer 9 · answered Feb 15 '11 at 19:53

Lots of great answers.

Even if I don't work for the 'big guys' and I'm not a guru, I'll add my 2 cents.

Be nice to people.

Try to socialize with your colleagues, spend a bit of your time with some of them everyday if at all possible. Go to dinner with them every once in a while, have a good laugh with them.

In other words, try to build a "community" if there isn't one, or to become part of it if it does exist.

Getting to know your colleagues will help you with getting along with them more easily. Plus, odds are good you will have fun doing it.

score 2 · Answer 10 · answered Feb 15 '11 at 20:31

As well as all the good stuff submitted by the community (above), I'd also expect to see evidence of some hard skills. Not perfection or über-geek powers, but a good working knowledge of the basics and basic concepts. You got the job already (congratulations by the way!) so you're pretty much there.

But refreshing your knowledge and/or getting up to speed with the tools, languages and technologies your company uses will mean that you'll hit the ground running and create a good first impression.

A hypothetical perfect junior developer will know the fundamentals of such things as

the language.
I/O
OO concepts like inheritance
Object interfaces
database access (esp. with regard to how they do it at your new code 'shop)
the HTTP model
CSS
JavaScript/JQuery
database design
SQL and stored procedures
the IDE(s) you're going to be using
relevant frameworks (you mention Spring)

and so on. He'll be able to concentrate on picking up new skills without having to stop and learn basics. He'll be able to plod on (asking as many sensible questions as he likes - most Senior devs love being asked sensible technical questions) with the routine fare of online forms, admin pages that many juniors face for the first few months. Becoming a reliable, junior dev may be your first team initiation test ;-)

When I was starting out as a junior in the web team of a large corporation, the bulk of the initial work I was assigned was somewhat uninspiring but taxed me to the point where I hit the books every night so I could understand what I was going to have to do the next day. I got through it, but that was a stressful five or six months after the relative luxury of my Masters course ;-)

If you can do all the basic stuff efficiently, you get more interesting stuff to do fairly quickly and this will of course help advance your career.

And echoing what many above have said, the world of computers and code is constantly evolving. You will need to learn new stuff every other day. Keep your mind wide open and try and keep sight of why you have embarked on this in the first place - because you <3 it. In the years to come there may be times when this will not be at the forefront of your mind. Enthusiasm will get you through over most of the bumps and hurdles.

Having said all that, my experience of the last twelve years or so suggests that most juniors don't stay in their first company forever, so don't get too hung up on being 'perfect'. Making mistakes is all part of the process that will get you from junior to wherever you want to end up. I've been doing this for a while now and almost-delete a production database pretty much at least a couple of times a year.

Good luck with your career.

+1 for having an answer that mentions something specific to programming, and therefore can't be moved unedited into the boyscout manual. — psr, Jan 20 '12 at 23:02
Lol. Yes there are a lot of platitudes within this question ;) — immutabl, Jan 23 '12 at 15:58

score 1 · Answer 11 · answered Feb 15 '11 at 14:05

(1) An open mind. You don't want someone who is institutionalised into using language X and environment Y for every project. You want someone who can recongise when a particular techonology will not cleanly solve a problem and offer good alternatives. On top of that, you want someone who can challenge conventional thinking and come up with solutions that motivate the business. You may experience this yourself, but I've found that people get so used to a process that they don't change it, but they still complain about the amount of pain it causes them. Usually when I arrive, I look at how to improve that and offer solutions to my manager. Now, I'd also say, that the personal should be "diplomatic" about his/her suggestions :)

(2) Good domain modeling skills. This a a pretty big one that I've found some people overlook. In some of the places I've worked, learning about the business is 'getting your hands dirty' and people shy away into purely techincal problems like integrating spell checkers into version control etc and they don't invest a lot of time into improving the business. Being able to look at a business and creating models (simplifications) out of it and communicate that to various audiences be it spoken, visual (UML, SSADM or whatever) or a bit of both, you want someone with that mentality.

Two books I can recommend on the subject are: The Passionate Programmer and The Pragmatic Programmer. Both books offer good advice to junior and senior programmers alike.

+1 for the book recommendations; OTOH domain modeling skills take time to mature, so I wouldn't expect these from a junior. But striving to understand the business viewpoint and solve the users' real problems is important indeed, at any level. — Péter Török, Feb 15 '11 at 14:09
Peter, through university (at least from what I've seen) a developer would build up a strong set of analytical skills. This is really the goal of modeling, extracting expertise and making it learnable to other people. So, I'd say this is a fundamental skill I would expect from most developers. Being able to frame a particular problem at a micro/marco level and explain it to say a financial trader, get feedback and communicate that back to your team mates. That's just my take on it though. — Desolate Planet, Feb 15 '11 at 14:13

score 1 · Answer 12 · answered Feb 15 '11 at 15:22

Taking the initiative. I have had many people who don't do this at all and always wait to be told exactly what to do. If you see something that should be improved, do it. You have an idea to improve something? Bring it forward. Need another skill to improve on something? Learn it.

Shows that you care about what you're doing and want to improve.

score 1 · Answer 13 · answered Feb 15 '11 at 20:05

Not to scare you at all, but one thing I am going to warn you against that in every single company I've worked in, are the big dirty huge scrolling methods, and badly named objects that make you dread opening the source files in sheer shock and horror of such a mess. The places you'll usually find these are in the event handlers for "OK" buttons on dialogs, or the "Submit" button on web-pages.

I am begging you from the bottom of my heart. Please install a mental alarm bell, that when a method begins to look big, and by big, I mean more than 10 lines or so, think about creating another method... so many methods later, you will understand just how much responsibility the object you're developing in has.

The next alarm bell I'd recommend, is the 2-3 parameters max in a method. If you see methods with about 10 input parameters, say hello to functional programming in an OO language...

Sorry for the slight frustration expressed in this response, I just cannot scream it enough how beneficial it is to learn how to write clean code.

Please grab yourself a copy of Robert. C Martins Clean Code . Read it weekly, take it out for dinner, sleep with it under your pillow, have a copy of it in the toilet, and print out a few pages and stick them on the ceiling so when you go to sleep, you can read them before you nod off ;).

I wish you all the best in your career. Your passion at this point already shows that you will do great.

score 1 · Answer 14 · answered Feb 15 '11 at 20:31

The only advice I can offer is never stop learning. The way that those rockstar developers got there is by taking time to learn new techniques and languages are their own free time. While it is great if you stay there for 10 years, when you come out you will only know Java + Spring + Hibernate. This is why in my free time I look at the .NET platform, Python, and the occassional C++ code to remain active. As someone that is working on an MS in info sec, time can be precious and it must be spent wisely.

score 1 · Answer 15 · answered Feb 16 '11 at 01:00

The ability to use google. Really.

Not that I would never help anyone, specially a junior colleague. But there is nothing more frustrating that having someone not doing due diligence in solving problems, continuously.

My advice to junior soft. engineers is to do your due diligence in solving problems. Use google, wikipedia or stackoverflow diligently and methodically when you don't know something.

Don't wait too long before going to a more senior co-worker for help - that depends on the type of organization, though. In a good company where people help each other, if you spend more than a half a day trying to find an answer, don't hesitate to stop your own research to ask for help.

In other organizations where people are always mean to each other, you might have to spend a few days on your own (documenting everything you have done and everywhere you have researched) before asking for help. In such companies, documenting what you did helps so that you can show them that "you did google it" because that will be the first retort they'll throw at you.

But regardless, the essence of what I would look for in a junior engineer is to do his due diligence in trying to solve a problem instead of expecting to have answers handled to him all the time. In a nutshell, show me you can use google.

score 1 · Answer 16 · answered Feb 16 '11 at 06:06

1

Passion about work
Willing to learn more & more & more..
honesty
consistency

answered Feb 16 '11 at 06:06

Jigar Joshi

376

score 1 · Answer 17 · answered Feb 16 '11 at 08:13

Great answers there, if you follow all of what the people say here, i am sure anyone will be good at what he/she is doing,

Just want to emphasize a few points.

Be humble, dont be afraid to give your opinion, but once an opinion is shared don't hold on to it, be ready to learn from others.
form relationships with your team members, people as much as we want to work with smart and well established programmers, we still need people who we can talk to, having a healthy relationship with you team members will greatly help your career.
Be proactive, dont wait to be given work, find work, propose new ideas to the environment, even if they are not accepted, this will increase you value to the company.
Share with others what you learn, this will increase the level of your understanding, increase your value to the company and to the community.
Finish what you start, committment is a great quality to have.
Stay happy and don't get dissapointed when things are not going as planned, there will be ups and downs, but hang on there

All the best in your work

score 1 · Answer 18 · answered Feb 16 '11 at 09:07

One skill I don't think many Jr Programmers have, but is a really good one, the ability to create your own tools. You can save a LOT of time and effort with a few well made custom tools. And they don't have to be anything fancy, most of mine are 3 line shell scripts, though a few are a lot longer.

But learning to automate things will make your life easier. (And impress your co workers when you can get things done well)

score -3 · Answer 19 · answered Feb 16 '11 at 12:05

-3

A strong dislike of Java and C++.
A basic understanding of operating system internals, algorithms and data structures.
Excellent proficiency in C, and at least one scripting language.
Working knowledge of one mainstream VCS (Mercurial, Subversion or Git).
The ability to work proficiently on the command line.
Dislike of Windows, and the occasional home use of a Unix-derived OS such as Linux, BSD, or Solaris for development or general use.

answered Feb 16 '11 at 12:05

Matt Joiner

206
2
6

I don't think a strong dislike of Java/C#/C++ is important as much as understanding that the world does not start and end with them. Java has its uses, but so do Ruby, PHP, Erlang, Lisp etc. – Zachary K Feb 16 '11 at 12:38
How long does it take to develop working knowledge of a mainstream VCS? – Andrew M Apr 06 '11 at 18:25
@Andrew M: It can take weeks to become proficient with the plethora of tools surrounding a VCS. Diffs, branches, patching, merging. Then there's working around the limitations, or excessive complications of each VCS. – Matt Joiner Apr 07 '11 at 02:34
@Matt: I see, thanks. So what's the best way to do this on your own? Would just using it for your own pet projects be good enough practice? – Andrew M Apr 07 '11 at 08:53
@Andrew M. Probably not. I use Mercurial for my personal projects, it only really gets interesting when I merge changes from my different machines (I write shit all the time). You'd need to work with a few other people to get the full benefit. – Matt Joiner Apr 07 '11 at 10:40
2

Your first and last bullet points have little to do with being a good at developing or learning (the primary things you need from new developers.) Having a "Strong dislike of XYZ" is only useful if everyone on the team shares that dislike. If everyone doesn't, it's only going to cause rifts. There's no difference between a Windows-hater and a Linux-hater except that they're both haters. On the other hand, someone with reasons to dislike something based on personal experience mean they have something to bring to the table - THAT is worth having... But using Suse at home won't make you smarter. – corsiKa Jun 15 '11 at 20:29
@glowcoder: Using Suse will make you worse with Unix. Your comment is justified despite this one error. – Matt Joiner Jun 15 '11 at 23:10

Which skills would you expect and appreciate in a Junior Software Engineer?

19 Answers19

Linked