Take the 2-minute tour ×

I currently work in tier 2 support for an ISP, but don't want to remain here indefinitely. My overall ambition is to be a programmer as it is what I really love to do. The problem is that I came to this conclusion later in my career path and have had only the chance to go back to school to earn an AS in Computer Science and have had no positions as a programmer.

Being out of college for a long time now makes it very hard to go after a low level position as I don't have a BS (and realistically at this point, it won't happen for a while, if at all) and employers only seem interested in fresh graduates.

I have had the opportunity recently to work on some special projects at my current position that involve coding in my preferred languages to solve various problems. I have now written various tools using a multitude of languages to solve these problems. Now I am not necessarily what I would consider competent in these languages, but I can get around them and I know all the fundamentals (autoit, vb.net, python, perl, pascal, c#, php, batch, bash). I am also very good at finding a way to code what I need when I don't know upfront how to do it. I have some code samples for all these languages that I have used to solve problems at work. How do I incorporate this experience into my resume to be a more viable candidate for an entry level position?

share|improve this question

closed as off-topic by MichaelT, gnat, Corbin March, Robert Harvey, Kilian Foth Sep 2 '13 at 8:38



add comment

5 Answers

up vote 9 down vote accepted

Though using code samples is a common sight, the act only helps you solve a subset of problems. Advertising yourself as a copy-paste programmer is a venue where you won't be taken seriously.

You can advertise your skills differently though: Start listing what skills languages you've used so far. Eg.


Then try to recollect what the biggest problem you've used it for, what the skill useful for, or for what benefit it was for. Bonus points if you have screenshots and (even better) can put how much time or money you've saved by doing so.

php - 
    Fixing critical bugs in a web applications. (OK)
c# - 
    Created a small windows application for quick 
    statistics that business could use to quickly 
    gauge the business. (BETTER)
python - 
    Wrote an automated image resize script that was 
    30% faster than an older one, saving about an 
    hour of manual labour or so with the assets we 
    have in-house. (AWESOME)

This is a list you really should keep updated continuously wether you work with anything professionally or not. It is a good way to keep your examples fresh in your mind and also in the future keeping in mind what kind of benefit you give to your company. Better is to keep a list of projects instead of languages because they give a better view of things that you've done.

In the mean time, why don't you try to challenge your programmer self. The more you push your programming boundaries, the better you'll become at this "programming stuff".

  • Solve some programming problems. Such as CodingBat (Beginners - Intermediate) or Project Euler (Intermediate - Experts).
  • Use cool tools, if you don't have the time: read about the cool tools.
  • Read some blogs on best practices, design patterns, TDD/BDD, or whatever your programming kink is to find the cool tools.
  • Subscribe on twitter to people who are programmers and read the linked articles on cool tools that seem interesting (but skim the rest).
  • Write an app for yourself that solves some pain point (this goes a long way). Bonus points if you can make it a useful cool tool.
  • Go to github/bitbucket, find a project of a cool tool, look at code, clone project, tinker with project, be inspired by project.

Whatever you do, never ever LIE about what you've done. There is nothing to be ashamed of if you've worked with IT, it's usually a merit. You were a "user" once. Be honest but be also useful for your new position. Every time you apply for a new position; always be thinking what you can benefit the prospective company.

...and I've used to work at a factory counting peas. Now I code and hack on web application stuff and enterprise solutions.

share|improve this answer
I have made similar notes, but not by language, by project, where I document the changes in the code through the development process. I have made a number of desktop applications on my own in order to teach myself common concepts and push myself to learn. I will look into CodingBat and Project Euler though, those sound very useful for learning. –  MaQleod May 9 '11 at 19:55
@MaQleod: You can do the same thing by project (and should). Since you've mentioned languages you've used I only exemplified with that. Projects are better though; as the context of technology usage is more clearer that way. (Edited the answer to reflect this). –  Spoike May 9 '11 at 20:11
I've edited the question to add some suggestions on actually presenting the code samples, collaborative work and personal projects along with the resume, any suggestions on that? –  MaQleod May 9 '11 at 22:58
MaQleod: You should ask a new seperate question on this site for that. –  Spoike May 10 '11 at 7:56
add comment

First, Don't lie.

Second, I went through this myself. Here's how I handled it.

First, the name of the position:

System Engineer / Programmer Analyst

I put the name of the position that I'm actually hired for in the first part. The second position is what I spent a non-trivial amount of my time doing.

Secondly, I only put those things on my resume that directly related to programming. So for my 'System Engineer / Programmer Analyst' time, you only see the programmer analyst part.

share|improve this answer
I had a similar thing with my first position as a Technical Support Engineer - just list the responsibilities you had, and stress the programming projects you worked on. –  HorusKol May 9 '11 at 23:56
You keep saying "don't lie". Why? Many companies lie to the candidates about the nature of work. Other than lying is 'unethical', can be hard to maintain, and might be against one's religious/military/boyscout/other believes, what is the big deal about lying? I have known people interviewing for a C++ position at a large Hedge Fund, going through a grueling interview only to be put on a clusterfuck of a project built entirely in ... MS Access 2000. Leaving after a year, they would lie that the actual work was in C++. That person read C++ books to maintain sanity. Whats a poor programmer to do? –  Job May 10 '11 at 23:06
@Job This industry isn't as big as you think it is. The people you interviewed with are going to remember your resume, and if you start telling them stories about your previous job, it's really going to be hard for you to remember what you lied about. Then, they aren't going to trust you. That's why. –  George Stocker May 11 '11 at 0:47
add comment

In short, don't use anything that isn't programming-related on your resume.

If you haven't done so already, get involved in OS projects. Get a profile up on Github or Bitbucket and start hacking away at projects, either forked or ones that you've built. Both have their strengths - forked projects displays your ability to work with and understand code that isn't yours. Projects that you've created from the ground up showcases what you can do.

Get involved with programming groups in your area. Network. Get to know people in whatever domain you want to target. Learn what you need to know (if you're lacking anything) to get your foot in the door. More times than not, getting that job has more to do with who you know than what you know.

Are you familiar with basic engineering concepts (i.e. basic algorithms, design patterns, etc)? If not, spend some time on those. When interviewing, you'll generally be asked some problem solving questions that you need to use some of those concepts to solve (well, without brute force anyway).

If you already are familiar with these, take a look at the domain that you're primarily interested in. Figure out what language(s) is/are in highest demand. Then, start learning that inside and out. Having a lot of languages that you're comfortable with is a good thing, but not being able to sit down and write something in any of them without a bunch of Google'ing isn't so much.

Above all though, make sure that your resume is tailored specifically for a programming job.

share|improve this answer
+1 for network. My experience is that there's definitely entry level positions around, and some employers would happily give those to someone like the OP vs. a fresh college grad. A Github profile with some activity and potentially some blogging about what programming stuff you work on can go a looong way. –  qes May 9 '11 at 18:58
I am familiar with some basic engineering concepts, but I have only taken entry level programming courses, so I know I have a lot to learn in that aspect. I have considered starting on an open source project, but have no idea where to begin on finding one I believe I can actually help out on. I'll check out Github and Bitbucket, I have never visited either of those sites in the past. What level of complexity should a project of my own show? I have done a lot of projects, but most of them are fairly basic in comparison to others in the same category that I've looked at. –  MaQleod May 9 '11 at 19:59
@maqleod: Find something that you like or you're interested in. If you want to get into game development, fork a game. If you want to get into business app development, do the same. It doesn't really matter if whether or not your changes get merged back into the original product (although obviously it's a great bonus if they do) - it's more about showing your capabilities and passion and learning real-world development. –  Demian Brecht May 9 '11 at 20:06
@maqleod: Level of complexity doesn't really matter all that much either. If you haven't worked on anything like this before, the easier the better - some OS projects are poorly written and/or have a ton of legacy code (i.e. C/inline assembly for OS games that have been around for ages). Get your feet wet before diving into the enterprise-level apps :) –  Demian Brecht May 9 '11 at 20:07
add comment

Seek a job with a company you want to work for. But apply for a QA position. If you know what you say you know, it can be better to start with a company in QA until they get to know you. Then you can hire within. Once you get experience as a programmer, it will start to fill out your resume for better positions.

share|improve this answer
add comment

Most impressive thing I can see a junior programmer doing that will get them a job interview with me is to have a blog that journals their trials and tribulations solving programming problems, documenting their approach and thinking.

Be careful, example source code without context can be negative if the code isn't idiomatic and absolutely correct and accurate. By context, I mean in a blog post you can explain your problem, how you solved it, how you made it more idiomatic to the language you chose, and why do did things the way you did them. Incorrect code won't get you an interview for sure.

An example is people not using common well know standard library modules and instead writing their own implementation. This would be a big negative, not using the Comparator class and the Comparable interface in Java and writing your own implementation of some sorting routing would be a big turn off for me, unless I was 100% sure it was done for some academic exercise and was noted that the author knew about the proper idiomatic way of doing this.

Blogging about discovering some new API or framework or library and what you like and more importantly dislike and why, go a long way for people hiring to see how you think.

Other things that are impressive is of course a high stackoverflow.com reputation and intelligent questions and and intelligent answers.

share|improve this answer
In this case, can't code comments be just as useful to explain design of the code and thinking behind why certain statements are used and not others (to avoid a bug, to make the code faster, etc). I was under the impression that was the purpose of code commenting. –  MaQleod May 9 '11 at 19:50
good code should be self explanatory and should not need comments. Also comments on reasoning can become stale if the code changes and conflicts with the comment, bad impression. –  Jarrod Roberson May 9 '11 at 19:55
In collaborative environments, certain statements may be used to prevent a conflict elsewhere. Someone else might not know that and choose to edit the code to what they feel is a better statement. If the code is not commented to express why it is written a certain way, can't that lead to unnecessary problems in the future? –  MaQleod May 9 '11 at 20:01
Just as a side note: I've found production Java code that had a list that didn't implement the List nor the Iterable interface; even though it has an iterator() function. That makes things frustrating because you can't do the shorthand for loop for iterators. –  Spoike May 12 '11 at 10:24
add comment
