This is Argyn's blog. I comment on topics of my interests such as software, math, finance, and music. Also, I write about local events in Northern Virginia, USA and all things related to Kazakhstan

Friday, March 07, 2008

Why do people keep putting stuff in resumes/CV, which they don't know about?

My first American recruiter told me that if your resume is 10 pages long then you must have invented water. It's true that many people think that it's cool to throw everything they have ever touched into their resumes. So, you get these 5-10 pages long resumes with a long list of acronyms and buzz-words, and dozens of tools and technologies.
I can tolerate that. Huh! I did it myself :) The reason is that recruiters search by keywords, and it makes a sense to have all important keywords in your online resume.
However, I wouldn't put anything into the first page of the resume, especially in summary/objective section, unless I really know the stuff. For instance, many people put their skills list on the first page, then they list all programming languages, which they have ever used or studied. What's the issue with this?

Well, the problem's that if I find out that you don't know something in your first page of the resume, then the credibility of entire resume is under question to me. I can't test the depth of your knowledge in 30 minutes. It's impossible. So, I have to rely on something. This something is the resume/CV. I assume that it's honest and correct, then will check one or two claims in resume, especially on its first page. Than more issues I find in resume, then less credible it is. Basically, if 3-4 claims turn out to be exaggerated it makes entire resume useless to me. Note: "resume", not the person.

For example, once we got this guy with a nice resume, and it has way too many programming languages listed. I said "Do you really know all of them? Can I ask you a question about Fortran?". He said it's Ok to ask Fortran question. The question was "If you have a subroutine which accepts one parameter of type REAL, can I pass an array of two integers instead?"

Something like
SUBROUTINE FOO(R)
REAL R

then
INTEGER I(2)
DATA I/2*1/
CALL FOO(I)

He couldn't answer. He should have told me that he didn't work with FORTRAN in real projects since after school, or something along this line, then decline to talk about FORTRAN. It wouldn't sound nice, but it was worse to claim that he knew the language and didn't know an answer to a very basic question. You never know who's going to interview, maybe it's someone who spent a few years doing FORTRAN :)

The other case was a guy who said he wrote rules engine in some fixed income project for a big mortgage company. His resume was full of financial terms right on the first page. Then when one of us (who happens to be MBA) asked a couple of very basic questions like "What's IRR?". He couldn't answer. His understanding of financial terms was that of some numbers in data fields, which he inputs into certain formulae to convert into other numbers. He didn't even remember those formulae. Someone else asked him how his employer makes money, what's its business. Poor man had no idea, could not name participants of mortgage securitization industry. Maybe he was a good rules engine guy, who knows? He shouldn't have claimed domain knowledge, when he didn't have it. Also, a little curiosity wrt the employer's business doesn't hurt.

It's probably wise to use more generic terms when you don't know the very well. So, using "mortgage securitization" is less risky than "PAC bonds", because in the latter case you can always cop out with saying that you didn't work with this or that aspect of the subject.

No comments: