| ||
|
This community works best when people use their real names. Please
register for a free account.
Other Groups: Joel on Software Business of Software Design of Software (CLOSED) .NET Questions (CLOSED) TechInterview.org CityDesk FogBugz Fog Creek Copilot The Old Forum Your hosts: Albert D. Kallal Li-Fan Chen Stephen Jones |
After I graduated I had many technologies listed on my CV. I really liked my university, becase we did try lots of different stuff. There were bits of assembly, networking, C++, java/struts, C#/.Net, SQL. Now I've been working as a programmer for almost 5 years. Most oif the time doing C# and SQL development. While I feel i still could program in other languages (perl, java, or C) I don't know the libraries as well as .NET framewor and I my expereince with C# and SQL is incomparably bigger than any other technology. Is it ok, to list only C# and SQL on my CV. Also what if did some, byt very little C in my current job. Should I list it on my CV?
Targeted is better. Each time you apply for a job adjust your CV so it specifically demonstrates the specific skills the employer is looking for. Drop or deemphasize stuff that is irrelevant. Actual experience software development is almost alway relevant, but classroom experience five years after the fact is irrelevant unless it touches on a specific job requirement. Do not list every language you can write 'hello world' in, because most jaded CV reviewers will assume you are padding your CV because you don't have any real skills . If the job description mentions a technology as desirable, and you can write the equivalent of 'FizzBuzz' using it, you can list it as a skill, but don't claim to be an expert in it, and for gosh sake, get some practice with it before you go to an interview.
I gotta say, I love the guys who come from school with a CV full of 'experience' in java/c/c++/perl/python/....... If I ask a very few pointed questions about each of these languages, followed up by a little programming test, this 'experience' falls to the wayside. At the very least, list your competencies in order of expertise and make it clear what you're REALLY good at as well as what you can do with a little refresher. Don't list stuff you couldn't sit down and start using right away (that doesn't mean 'be productive', it just means that you would be googling every feature, every other minute). Sure, you wrote c++ five years ago; what could you write today? Same with perl. Any decent tech interview is going to find out what you can really do (and really can't do). And, as the previous poster pointed out, now that you have experience, target your resume to the position. Good luck, don't get tripped up by listing too many competencies, just those that you could hit the ground running with today.
There's a trend now to divide expert skills from occasional, so these will be listed in separate areas. The theory is that auto keyword filters pick up acronyms, but a close reading reveals all. Even so, everyone's definition of expertise varies. shlabotnik mentions testing to show someone doesn't know C++. One has to be careful with that. Every company uses a different language called C++. No two are the same. C++ is complex enough that I could definitely give a C++ test that almost all expert C++ programmers would fail. But that's pointless. If looking to separate the fakes from the reals, it does no good to give a test of library trivia or template metaprogramming antics. Most really good programmers will not know that stuff. I see these sorts of questions on interviewer blogs. The interviewer is looking for a clone of himself, not a competent programmer. You can turn it around and make the interviewer fail a similar test. Have them bring in code they wrote and explain it works well, especially if it's a program that's publicaly available with their name conspicuously attached. But when dealing with someone whose name and code are already out in public, you don't really need to interview for skills at all. Most programmers can't bring in code, claiming IP restrictions. That's fine, but then you have to quiz them. Don't spend too much time on it. A guy was telling me his company has an 8 hr long programming test that you do at home. Except 8 hrs is how long it took the guy who came up with the test to do it. I am sure all their people claim it took 8 hrs or less. I looked at the test, it would take me about 80 hrs and I am good. What a waste of time. Think of how many good programmers they overlook with this scheme.
"Same with perl. Any decent tech interview is going to find out what you can really do (and really can't do). " I tend to disagree with this. I have written a few hundred perl programs and a few dozen of them are quite large. I don't write them often, day to day programming is in C and C++. When I write in perl I open up my other perl programs as a reference. If you asked me how to read in a file and scan through it, the most basic perl thing, I could not tell you. Something like @=$_, then foreach $line in $@ or something like that. I know that is wrong, yet I have written working perl systems far more complex than most perl programmers. Yet I can't answer even basic questions about it. Pointer syntax especially, that is tricky. How to pass a reference to a pointer to a hash to a function. man, I have to look that up everytime. My brain holds very little syntax information. And almost no API info. Most I get from the context of what I am working on at the time, and referencing previous code where I figured that stuff out before.
If you can't write one single line of helloworld in the language you're an expert in, I'm pretty sure you can't do much else either. It doesn't have to compile, but it sure better LOOK like java/c/perl/c++/python. I'm with you, I have a hard time sitting down and writing perl programs. I look at running programs and remember how to create new programs. But, then again, I don't purport to be an expert in perl. However, the same is not true with C, java and python. (And I do claim to be expert in the first and far better than above average in the 2nd two.)
True, I can't write helloworld in perl idioms without looking up WTTF the print-to-console function is called. And yet I am a pretty good Perl programmer. I haven't written anything in about a month and that was bug fixes to an web site spidering program that didn't involve interaction with the console. Is it print "hello world" ? Probably something like that. Now I can do hello world in C since that's what I'm working in this week.
I'd say use linkedin, use facebook, build a social network, contribute to open source, go to user group meetings, go to conferencs, etc. You want to get to a place where the resume is a afterthought that HR says they need. Your Mileage May Vary; I understand Andy Lester has some good writing in this area, though: Uhhh ... here - land the tech job you love: http://www.amazon.com/Land-Tech-Love-Pragmatic-Life/dp/1934356263/ref=sr_1_1?ie=UTF8&s=books&qid=1258652597&sr=1-1 | |
Powered by FogBugz
