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

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.

Answer 1

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.

Answer 2

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)

Answer 3

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

Answer 4

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. ;)

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

(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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

• Passion about work

• Willing to learn more & more & more..

• honesty

• consistency

Answer 17

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

Answer 18

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)

Answer 19

• 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.