[RESOLVED] Languages / Resume Description

[ssmith147]

I have a very general question concerning resume creation and known programming languages. I did some searching for similar discussions, but I just don't think I was using the right search terms.

I am fairly comfortable using VB.Net, C#.Net and Java. I am also familiar with C/C++, Perl, Python and I am now studying Ada.

So how do you describe your experience on a resume without over-inflating it, but also without selling yourself short? For example, I know C#'s syntax and basic construction, but I haven't written any serious software in the language. Due to my experience with both Java and VB.Net I can overcome any challenges I run into with C# without too much trouble. How do you present that in a condensed manner that other professionals recognize?

Or, stated more generally, how much should you know about a language before you can say "I know the X language."

I'm looking mostly for feedback from professionals in the field as well as folks who have seen the good/bad/ugly in resumes and can give me some advice. As a background I'm a CS student who is also a career changer with 13 years of experience in another field. I'll be graduating with my BS in a few months and I am starting to look for a position as a programmer now.

Any help / advice that can be offered would be greatly appreciated!

-Will

[Shaggy Hiker]

The thing that jumped out at me right off was "C#.NET". Don't say that. There is no C# that is not .NET, so just say C#.

Others will have other opinions, but I would approach it like this: Would you feel comfortable if you were asked to write a program in language X? If you answer yes, and are honest with yourself about your abilities, then I would say you "know language X". If, on the other hand, you feel that you can read language X well, but would need to do some reading or research before writing an actual program in language X, then I would suggest that you find other wording, such as being "familiar with language X". I would not say "I don't know squat about language X.", since that is not a help to anybody, even though it is kind of fun to say.

After all, if you have done a fair amount of programming in any one language, you are probably well aware that you don't know EVERYTHING about the language. Problems will arise that you will have no experience with, especially in the .NET languages where new features show up with every new version. Therefore, you don't have to be a language lawyer to be proficient in a language, and shouldn't downplay your knowledge excessively. You need to recognize that you will still be learning new things, even though your resume will focus on the knowledge you already have.

[baja_yu]

Good info from Shaggy, and I agree on the 'knowing' statement. I've met people who claimed to know a language just because they went through a book about it cover to cover and familiarized themselves with the syntax, but never actually wrote anything in it. Definitelly not a good idea.

One thing you can do is provide a short history on projects you have worked on (describe them) and languages you did it in.

[ssmith147]

Shaggy, your approach seems very smart to me and I think that's the approach I'll take (you know, I've been putting C#.Net on my resume up until now...DOH! ). I'm glad to hear that I can say something simple like "I am familiar with language X" and it won't be seen like I'm a moron (notwithstanding the C# issue).

baja, I've actually been building a portfolio online with my academic and personal work listed by language, so I appreciate your feedback- somewhat encouraging to think I;m on the right track there.

Thanks for the advice, guys. I sincerely appreciate your taking the time to help me out with this question.

[Blakk_Majik]

I've always been bothered why it matters if you know C# or VB, if you know .NET.

Anytime someone asks me what language I do most of my work in, I say .NET. Then proceed to get into a 20 minute conversation (with someone that isn't a .NET developer) about why .NET is .NET, regardless if you use C# or VB.

[techgnome]

It's a syntax thing... I go through the same deal anout .NET being NET being .NET... but I'm still faster in VB than I am in C#... because I'm still getting used to th syntax. My fingers aren't trained to hit the; at the end of the line... and I constantly forget curly braces some were. Getting better at it, but it still slows me down some.

tg

[03myersd]

Oddly enough techgnome, I now have the opposite problem, where I insert curly braces and semicolons into VB code.

[techgnome]

Ironically I don't have problems switching between PHP and VB... but I do have problem switching between VB & C#... go figure.

-tg

[03myersd]

I think its just the mindset is completely different. Its similar to the way where I drive a car the same make and model as my own and I have difficulties with stalling etc, but I have no problems at all if its a completely different car.

My next language is going to be C so this will be interesting to see how C# influences that.

[Pradeep1210]

I hate C# for its curly braces, semi-colon and case sensitivity. Rest is all good.

[dilettante]

As far as job applications and resumes go I would omit anything you haven't done much actual work in, or perhaps provide a single sentence listing the languages you have some familiarity with.

When emphasizing the ones you feel strong in you might briefly describe a few major applications you've used them on.

Just listing languages will get your resume past automated resume ranking software (yes, people use these things) and Hooman Resources (those fat Ferengi). Showing that you did some "deep" work with one or more languages will help get your resume nearer the top of the pile after that.


Be prepared to bring along samples of work to an interview. Don't bring a thick pile of code listings though. Find two or three good examples, which should consist of a few cover sheets: a sheet describing the project requirements and goals, a sheet showing the application's architecture at a high level (no flowcharts), maybe a user manual where appropriate. Go ahead and throw code listings behind that if you really feel like it. Be prepared to answer off the wall questions about these projects.

These don't need to be new programming projects. Non-trivial maintenance or conversion projects can be just as good - maybe better for some jobs.

The good thing about having a few of these and having them be brief is that interviews may often be done by a panel rather than a single individual. Some of these people may well be non-technical. Normally they won't have them prior to the interview, so they will hand them around and you want them to be able to get a quick (and positive) impression. No fancy binders, just staple them together. They might want to retain them for use during their deliberations.

If you're lucky you won't get one of those panels that sends you to the whiteboard and asks you to pseudocode a solution for one or more totally random quirky problems.

[praveeseo]

HI tO all I think its just the mindset is completely different. Its similar to the way where I drive a car the same make and model as my own and I have difficulties with stalling etc, but I have no problems at all if its a completely different car.