This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I've been thinking about this topic since reading this recently. The writer uses a rather extreme example of lying (claiming a degree where none exists), but it also points up lesser problems.
I did a major overhaul of my CV a couple months ago. A lot of it was innocuous. Do I really need 3 paragraphs about a job ending in 1993, or 3 sentences about something in the mid-80's? I refocussed the document to more directly support my abilities and aspirations as they are now, not when I wrote the first version of this thing a decade ago. All well and good.
But I did two other things. I took out a fair amount of puffery and piffle. Partially because my goals have changed. But also because maybe I'm more comfortable in my skin than I was and no longer need to do this. And was increasingly uncomfortable with it. So I whacked it and I like the result. Less is more. And I refocused on my current goals, expanding the portions which show skills supporting my goals and shrunk the sections which did not.
I've seen a rather paradoxical result to this. A couple of times in recent days I've been accused of understatement. One fellow in particular seemed to think it was a bit unethical not to put down the whole story.
Some of this is entirely deliberate on my part. I had a very intense project using Perl about 3 years ago which is barely mentioned. Perl is a great tool for shell-hacking but I DO NOT WISH to write another system using Perl. Special circumstances forced my hand that time. So the Perl episode is barely mentioned.
Another thing which is underemphasized is testing experience. Not quite a lie because I've never held a testing title. Not quite the complete truth because I have worn the testing manager hat among other duties and know enough about testing to be able to perform in a testing role. I don't normally aspire to those kinds of roles. As far as I'm concerned radical and exhaustive testing is a mark of the better developers. I'm gratified to see industry thinking migrating to that POV with things like JUnit and it's children and TDD. But I use indirection because I don't want recruiters ringing me with every junior testing role available based on a keyword search.
A third category of underclaim is home work. I do a fair amount of exploration on my own time when I'm working and more when I am not. I also read a lot. I used to put a lot of this on my CV but have largely cut that out. If I can't present it as commercial experience I either omit or de-emphasize it.
Given the reactions I wonder whether I didn't overdo the cuts.
What should one put on the CV and what to omit? Opinions anyone? [ December 09, 2004: Message edited by: Don Stadler ]
There have been a couple of occasions where I have acted just like you - omitting some part of my expierene because that was not relevant to the job. At least, it's a lot better than stating that you have experience when in fact you don't have it
I don't see how omitting experiences from your resume because you don't want them considered in hiring is at all dishonest.
Hiding periods of employment or unemployment can cause problems even after you are hired, but that's not the same thing.
As long as the experiences you describe really happened and your dates of employment check out you should be fine.
One exception - omitting your programming knowledge when applying for a system administration, operations, or security job may be an issue at some firms. They are concerned about ops people who can personally modify code.
There is a saying that says : "Be careful what you wish for, you may get it." In lieu to Don's posting, we could probably say : "Be careful what you put in your resume, you may get it."
I agree with Don. You have to think of your resume not only a reflection of what you can do, but also the first clue for prospective employee of what you are looking for. If I am still working full time during a job search, I do not want to waste my time for interview (even just a phone interview), if it could have been known that the position is not what I am looking for.
It happened to me before, got contacted for a phone interview and I pass to the second interview one, only to find out that I didn't qualify because there was a misunderstanding on my skill that I put in the resume (I told the truth in the first interview and the interviewer did not seem to mind, but the second one certainly did).
After that, I did similar to Don. I trim my resume (even though may not as extreme as Don).
Since then I got an interview then an offer for a position that was aligned with what I wanted.
Some suggest to put jargons in resume just so that you can pass the HR scan. That is probably fine, but I would ask to make sure I understand what the position is about and the skill set it needs. I think it is better to say 'No thank you' up front and wait for the next opportunity rather than wasting time in a series of interview just to find out later that you got an offer that you could have known you don't want. [ December 10, 2004: Message edited by: Joshua Halim ]
Joined: Feb 10, 2004
Originally posted by Joshua Halim:
Some suggest to put jargons in resume just so that you can pass the HR scan. That is probably fine, but I would ask to make sure I understand what the position is about and the skill set it needs.
I had to do that today. I have a contexts section in which I list various things I can do, and a recruiter asked me to add 'technical architect' to it to pass the HR screen for an architecture position. It's not untrue but I'm uncomfortable with it for reasons I'll go into in my next post.
Joined: Feb 10, 2004
I don't know, maybe this should be a new thread. But here goes.
What is an architect?
Many architects I've worked with content themselves with drawing lots of boxes and cultivating that noble look of leadership while leaving the hard work of actually making the sucker work to the peasants below them. It pays well and the hours are relatively short. When the wheels come off most often they won't make you fall on your sword because the fault was not with your beautiful vision but with the bovine stupidity of said peasants.
As you may have gathered from my tone I think that is a load of crap. And I don't care to be identified as that kind of person.
Another definition might be what I might call a senior developer plus. Someone who has been through enough projects to have a good notion of what kind of problems need to be solved and how to do it. This comes closer to my self-image.
Finally an architect could be what I think of as the owner. Or perhaps calling them the chef would be more apt. The person on the project who takes personal responsibility for making the thing work. I've done this too.
This used to be called team lead, technical lead, or lead programmer but today it seems to be labeled architect.
There is a strain of thought centered around Agile and xP which holds that role specialization is a bad thing. That responsibility for the architecture should be distributed within the team. Architecture isn't an up-front activity done by VIP's in the team but something many team members do every day. This makes much more sense to me. The old vision of the Architect is just so waterfall, you know? Iterative and TDD require a radically different view of architecture I think.
Problem is that I feel intensely uncomfortable about identifying myself as an architect. Effective architecture is often (dare I say always) a collegial function spread among a group of developers. So calling myself the architect feels a lot like taking personal credit for a team activity.
And yet. Most of those lovely juicy roles with real responsibility are titled architect. I want them and I can and have done them. I like the pay as well though the trouble is often not worth it as a strictly economic decision.
Couple of interesting topics in this thread. Regarding architects, a software architect is an experienced developer who can see the big picture and figure out where the important bits are. Experience is critical, but not the only factor. I've found that some good developers just aren't good architects. They can write excellent code when they are given direction, but they have a hard time making decisions about algorithms, communication methods, tasks, etc. Give this guy a good set of specs and he'll write some slick code. But left to his own devices he'll just spin his wheels.
Developers without experience tend to focus on the wrong thing. They want to hustle off and implement cool new features. But us old guys that are writing code that is going to be deployed in a business critical space know that the parts that matter are the unglamorous ones, like monitoring, management, and provisioning.
Getting back to architects, a good architect can implement his design. How much of the code he actually writes depends on the work environment, but he must be able to participate in design and code reviews and know what he's talking about. Like the original poster I have no tolerance for "architects" who just want to doodle on a white board and go home.
Joined: Feb 10, 2004
I've found that some good developers just aren't good architects. They can write excellent code when they are given direction, but they have a hard time making decisions about algorithms, communication methods, tasks, etc.
This is very true I think. After years of observation I've come to believe that there are at least two paths to becoming a competent senior developer. One you might call a language lawyer, although I don't mean that in a negative way at all. These are the people who tend to learn tools inside and out. They often write brilliant code, code which can leave one breathless with admiration.
The other path is someone with a lot of experience and insight into making working systems. Often these people are more into simplification and process. I think you find a lot of them among the Agile methods enthusiasts for instance. I think these people tend to make good architects. There is some injustice here in that I think both categories of developer I describe are equally valuable. Properly mixed they can make a good system excellent.