I am talking of stuff related to programming only and not system or network administration.

I am about to finish college and get a programming job, so I am interested to know about this. Although this may seem a subjective question, I think this is not quite and falls in the category of best practices.

I don't think a programmer can know everything about OS he works on, all the APIs of the framework he works on, all the features and quirks of the languages he works with, all the data structures and algorithms, all the settings for his compiler, linker, IDE etc. I don't think it is practical either. Or can he?

The usual answer is "most". What is this most? If you were to interview a programmer with about 5 years experience, what would you expect him to know? Or lets say if you were to attend an interview and you have about 10 years experience behind you, what would you brush up on?

closed as not constructive by Oded, user8 Jan 7 '12 at 11:50

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    It entirely depends on the type of work. What you need to know for front end web is different from back end web. Which is different from embedded, which is different from OS work... – Oded Jan 7 '12 at 8:47
  • 1
    Hi Michael, welcome to Programmers! While this might make a great discussion topic, it's way too broad a topic for the Stack Exchange style of Q&A. If there's something specific about software development you'd like someone to explain to you, feel free to ask about that, instead. – user8 Jan 7 '12 at 11:51
  • 2
    You should know your keyboard like the back of your hand. – user1249 Jan 7 '12 at 13:57
  • 2
    I do not understand why these kinds of questions get continually closed. WTF. The dude is fresh out of college. He's a Jr. Therefore his questions ARE gonna be open ended and non-specific. He probably doesn't even know what to ask which is why the responses he probably wants are anything that can help him. He wants general insight. You don't need a specific scope to answer his question. The answers in this thread are excellent. Even if this was asked 100 times, who cares, you're gonna get new and different and entirely new answers that are even different than in other threads. – WeDoTDD.com Jan 10 '12 at 6:06
  • 1
    This is a problem with stack. The whole point of th Programmers forum is that you can ask both specific and/or ask subjective questions that poll, give opinion, arguments, etc. Opinion is what drives good answers to a question like his. Everyone has had their own experience in the software industry so opinion is exactly what this guy needs. He needs a breadth of ideas, experiences, and insight here. So what if they're not specific, this is about general career advice.. – WeDoTDD.com Jan 10 '12 at 6:09

You need to know:

  1. How to Think. If you can't think, go work in some other profession.
  2. Know where to look. You don't have to know everything about something, you have to know enough to be useful, and enough to THINK "hey there needs to be a way to do X" and then go look it up.
  3. Know your limits. This means your abilities, your lack of knowledge, the fact that you don't know everything (and never will). A little humility goes a long way.
  • 7
    humility is rare in our profession, I agree. We need more humble developers that can say once in a while hey, I don't know how to do x, y, or z and aren't afraid to let down their guard and ask questions...even architect leats... we need devs who truly care about working together, not egoistical devs who think they are Gods and isolate themselves in their own Godlike world at work. – WeDoTDD.com Jan 7 '12 at 9:02
  • @CoffeeAddicat: +1. And I'd give you more if I could. – quickly_now Jan 7 '12 at 9:15
  • 1
    @CoffeeAddict: Being humble is over rated in my humble opinion. Coffee on the other hand is not... :-) – blunders Jan 7 '12 at 9:17
  • 3
    @Coffee - There is a complete lack of humility in our profession from what I've seen. When I worked in an investment bank, I used to go up to my boss and ask questions about things I didn't understand and she'd raise her voice so loud that everyone would hear. That was obviously a pathetic attempt to make me feel lousy about asking questions. – Desolate Planet Jan 7 '12 at 9:53
  • 1
    @Desolate yep, I hear your pain. We shouldn't have to put up with people like this in an engineering profession. It's an attitude problem by the majority of developers out there (I'm not saying all). I don't understand why there has to be a war of "I'm smarter than you"and huge lack of respect for your collegues...f that. We should all work together...learn, and move on. – WeDoTDD.com Jan 10 '12 at 6:12

Programmer Competency Matrix is a good enough checklist, and it's an easy, informative read, from a single source.

Norvig's classic blog on "Learning to Program in 21-Days" is also a good read.

  • @Expressions: Yep, no problem - at first though the question was as one might guess a little to open ended, but thought about it and dug up this check list I'd found a few years ago. – blunders Jan 7 '12 at 9:51
  • yea I like this one too...good one. – WeDoTDD.com Jan 8 '12 at 0:40

I'd like to comment on this because I think that even though this question has probably been asked a lot in these forums, it doesn't matter, you get different perspectives every time it's asked.

With that, here's my experience and I guess "wisdom or insite" into our profession. Some of this will overlap with what others have already stated but I'm listing my experience and then my philosophy/opinion/suggestions to you for each

1) Yes, as others have stated, you do need to have some level where you're able to digest complex ideas, process, and be able to work through and come to your own solutions in code to problems. On the other hand: You can learn to become a better problem solver over time if you have a lot of positive motivation to keep sticking with it, work hard, and ask a lot of questions. Most developers who say they know everything or try to appear like they do simply hide the fact that they've asked a lot of questions, worked their ass off in code, etc. to get to where they are at and to get as good as they appear to be

2) In our industry, again in my opinion, there is a lot of egos you have to deal with unfortunately. I don't see this as a good thing and it's especially a trait for a LOT of developers out there.

What you will find in my experience are one of the following type of teams:

  • "Code & Run" teams. This means all they care about is getting crap out the door fast, they could care less about code quality (clean code) or code that is maintainable later on. Stay away from these shops if you can. It's hard because even if you drill a company in an interview, you won't truly know how the team operates until you get the job and are about 4-6 months into it to see really how they code or if they truly promote teamwork and foster collaboration (ideas, etc.)

  • Average dev shop that is "ok". This means they care a little about code quality. They might have a few good devs on the team who work good in a team and have a positive attitude and then a mix of some devs who could have other traits such as egoistical, lazy, etc. So I mean it's kind of a hogposh shop but where the code isn't the greatest but tolerable

  • Great shop. This shop tries their best to really follow good design patterns. They may not be experts on design patterns but they know of good practices such as DRY, SOLID, whatever else. They don't necessarily expect superstars to join their team but they are looking for devs who are at least coding somewhat clean code and have a good amount of experience first. These are the teams you want to stride for...but you might have to go through a few shops to find good teams

  • Superstar Shop. This is a shop that only looks for the absolute best programmers but also best meaning programmers that have it all. They communicate well and work well as a team (positively with others for the better of the tema). Keep in mind every shop is gonna tell you yea, we only look for the best. Most of that is nonsense...they have good intention but a lot of times it's just marketing talk. But there is a % of shops that truly are looking for top talent. And you'll know that when you get into the interview and they're asking questions on threading, advanced design patterns, etc. So..to get to that level and if you want to work on a team that has this kind of expectation, it may take you a few years to get there

  • Superstar Shop with negative vibes/egos. There are shops out there that due hire top devs but where the majority of that shop can have a bunch of pricks who are superstars. So there are teams that just don't tolerate bad code but they are real pricks about it. It's not a team enviornment and you want to stay away from this crap. Our industry doesn't need it and neither do you

and one of the following types of developers out there:

a) Huge ego, knows everything, always wants to keep a distance from all, reveals little, has an attitude ...essentially not a team player and not someone you want to work with or have on your team

b) Devs who are there just to do a mediocre job and get the job done and go home. Personally I guess there is nothing wrong with it from an initial standpoint but at the same time I think our profession needs developers who are passionate and are willing to sacrifice and enjoy their craft to ultimately provide value but also to improve as a developer over the long haul because they care about becoming better

c) Devs who probably could make it but are too lazy, negative, or whatever other traits they possess that just causes hell for everyone but because mostly of laziness factor. Wouldn't want lazy people on my team...lazy engineers are not what we need in our profession

d) Devs who are good to great developers, who care about teamwork, who are willing to humble themselves, to teach others, to communicate, and to be open to constructive criticism on process or code (code reviews, etc.) and just simply care about being positive at work while working as a developer with all collegues. You want to work with these kinds of people, a positive supportive dev environment. Now I'm not saying that a team should be looking for leachers...you need to be able to hold your own weight but you don't want to end up on teams where they expect you to be a "star" developer and to never ask questions...that's a bad environment. Stay away from that...it's hard to find this environment in my opinion in our profession overall in my and other friend's experience throughout our careers. You can find good teams but they're harder to find than landing in chaotic shops with bad attitudes. So know what you're getting into, the grass is not always greener just because developers are so-called "professionals". I'm sure this can relate to any job probably but I think more so with our profession than most others out there.

3) One thing I learned the hard way is that if you are a perfectionist and care too much about good process and perfect code, it's gonna get you in trouble some day. Find that balance. You don't want pure sloppy code and you don't want to waste too much time to the point of your employer getting pissed off because it took you 2 weeks to get a relatively medium sized task done that should usually be done in lets say 3-4 days because you wanted it to be too clean. A good book to read and good guy to follow in our industry is "Uncle Bob". I am a big fan of his as are many developers out there. Read his blog posts on code and buy his book. I can't say how much wisdom and experience he has to offer people including yourself, who is just coming out of college about our profession in terms of best pratices, attitudes, philosophy, etc.:

his company blog: http://blog.objectmentor.com/articles/category/clean-code (and check out http://blog.objectmentor.com/articles/2009/02/03/speed-kills)

one of his many good books that I feel every developer should be reading or have read and have on your shelf: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

His personal blog: http://cleancoder.posterous.com/retarded-architecture

And a good video of his at a conference he spoke: http://www.viddler.com/explore/oredev/videos/36/

4) Don't stress yourself out about competing with all the devs you work with. You need to realize it's going to take you a few years to even master the basics in our profession even if you've done well in CS. It takes time, work hard, ask questions, research, be patient...and especially since our industry is now in such flux, don't get frustrated if you do not know everything. Focus on the basics first...know them well for the first few years. Don't over complicate your worries, you're a Jr. Developer trying to become better and that will happen if you work hard and get good at basic OOP first. A lot of devs in our industry still don't know the fundamentals because they haven't put the effort into trying to know them and that's a negative. You want to know the fundamentals first well (Polymorphism, Encapsulation, yada yada). If you don't have a lot of opportunity to do a lot of OOP in your first few jobs, make a huge effort to research and practice it at home by playing around with code with some fun pet project on the side that you enjoy.

I could make this post longer but I'll stop here. If you have more questions per my post just reply in the comments and we can continue on discussing.

Ultimately if you are a genius, super smart, smart, mediocre, or suck, no matter who you are at what level, if you want to make it in our profession you are always going to have to work super hard and continually try to learn and improve yourself and aim for the best you can be (code, communication, etc.). Our profession is not one to take lightly.

  • I would like to add that solving and partitioning blatantly complex problems is only the second step. The first is actually recognizing that there is a problem, and what the problem is. – John Weisz Feb 5 '17 at 14:22

How to find out what you don't know as quickly as possible ...

  • Do you mean find what you don't know, or find the answer to what you don't know? Knowing what you know, what you don't know, and what you don't know you know will only get you so far. Learning from doing, not by knowing is the way to the shining path of the future... :-) – blunders Jan 7 '12 at 9:28
  • Doing things wrong leads to suffering, doing things that someone else can do quicker and better leads to suffering, knowing who and where to go to for help is the way to the shining path of the future ! Way to many junior level people sit and stew on things that would be much easier to ask for help on and actually learn how to fish before they go out and build a boat when they don't need to! – user7519 Jan 7 '12 at 9:40
  • I don't know, while I'd agree watching someone beat their head mindlessly into a wall is a painful thing to watch, also believe that to often people rob other people of the chance to just fail, learn from it, and move on. Failing in my opinion is a huge part of learning. – blunders Jan 7 '12 at 10:33

Having roughly 10 years of experience myself, I'd brush up on algorithms (sorting, data structures, graphs). The biggest problem for me is that my last few years have been spent either in a leadership role, or dealing with higher level architectural problems that don't generally require lower level algorithm design and analysis as almost anything that you'd ever need at that level has already been written, optimized to hell and has been battle tested.

I'd also spend some time on projecteuler.com and interviewstreet.com solving problems to help me apply those newly re-learned learnings to help 'em stick.

  1. Learn maths. Programming is mathematics if you remove the visual effects.
  2. Use the right language for your program. Then, know at least the capabilities of the languages.
  3. Spend some time on algorithm before coding. If you are coding as a member of a group, study the algorithm together.
  4. If running speed is a matter and if you are free to fix the code for an architecture, use the routines specialized for your CPU, GPU, etc.
  5. Spend good time for debugging and testing.
  6. Be curious about almost everything about programming. You will learn with time.

Know your algorithm and data-structures thoroughly. Know how to accomplish common tasks with the language/framework and how an expert would do the same. Work, make mistakes, improve and let your experience teach you more for as long as you are in the industry.

My checklist for an interview would be

  1. Sorting, Searching, graph algorithms and basic of Dynamic Programming.
  2. Arrays, matrix, stacks, queues, linked lists, trees and hash tables.
  3. Object Oriented Programming and Testing concepts

Don't forget to keep in mind the time and space complexity of your solutions if you are aiming for one of those big firms people dream to get in :).

Best of Luck

  • 1
    "Know your algorithm and data-structures thoroughly": that's a pretty daunting statement given the sheer volume of each... Perhaps get a little more specific for an entry level interview. – Demian Brecht Jan 7 '12 at 8:44
  • Thanks Damien for the suggestion. Edited to be more specific. – Priyadarshi Kunal Jan 7 '12 at 9:32
  • 3
    @demian and indeed it's untrue. For example, when I want to sort a list, I'll more often than not call .sort() on the list object. – user4051 Jan 7 '12 at 9:32
  • @Lee Solving problems for application in real life can/will/may be different from doing them in interview. An interviewer would probably want you to solve a problem rather than simply answer it. – Priyadarshi Kunal Jan 7 '12 at 9:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.