kai_mactane: (Default)

I received a phone call at work this past week, while I was in the middle of debugging some complicated JavaScript. Usually, my desk phone shows the internal extension that’s calling me; this time, it showed a series of asterisks. Intrigued and confused, I picked it up… and discovered it was a recruiter calling me. Apparently a row of asterisks must be how this phone indicates “Caller ID blocked”. (Now I know.)

The next morning at 7:53, I got a call at home from a number that didn’t report any name. I always let those go to voice-mail. I heard another recruiter leave a message, including “it’s eleven o’clock”.

Two different recruiters in two days, making such elementary mistakes? I’ve been working on this article on the back burner for a couple of years, but it’s obviously time I finished it up and posted it.

Never Call a Prospect At Work

And I really do mean, never. You don’t know if your prospect’s current employer monitors calls. You don’t know if your prospect has already told their employer that they’re looking for other opportunities — but it’s safest to assume that they haven’t, because it is definitely not safe for an employee to tell their employer that. Especially in “at-will employment” states (like California), where an employer can terminate an employee at any time, for any reason or none at all, there’s an all-too-real possibility that the employer will just fire the worker immediately. (I’m not saying this would be a smart thing for the employer to do. And I’m not saying the likelihood is high. But it does exist, and it’s too much risk for the employee to take.)

Telling your employer that you’re looking for a new job can get you canned, posthaste. Having your employer find out from some third party that you’re looking for a new job can also get you canned. You know what’s the one thing that would be even worse than getting fired for being on the job market before you can find a new job?

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

I keep hearing about developers who, when interviewing for potential jobs, consider coding tests to be “a waste of time”, “insulting”, or “beneath me”. The logic seems to be: Once you’ve risen to the level of Senior Developer (or some similar title), people should realize that yes, you really do know how to write simple pieces of code. You can write functions that sum all elements in an array, or reverse a string, or whatever.

I’m not bothered by them. I’m far too aware of the great number of coders that, to put it bluntly, simply can’t code. It doesn’t matter to me whether they’ve risen to their level of incompetence, or they’ve been in sky-high architect territory for too long and gotten rusty at function-level coding, or they’re simply lying on their résumé and they were never able to so much as solve a FizzBuzz problem. The fact is, they keep winding up in interviews, and it’s (part of) the interviewer’s job to weed them out. As quickly as possible, to avoid wasting any more time than necessary.

Back when I was in my first tech job, as a Linux sysadmin, I was one of the people interviewing potential candidates. I decided it would be nice to set them at ease by starting off with a few easy, “warmup” questions. So I’d start off with things like, “What is a runlevel in Unix? What are the most commonly-used runlevels, and what do they do?” Or, “What port does HTTP use by default? How about SMTP?”

I was astounded to find that there were applicants who couldn’t answer these questions.

Not in the sense of, “I’m sorry, but I’d have to look that up” (though even that would be a little odd; these are things any Unix sysadmin should have engraved on their consciousness). No, this was in the sense of “A runlevel? Ummm… I think I’ve heard that term, but I don’t know those kinds of details.”

My only real quarrel with FizzBuzz is that, at this point, any developer worth their salt is familiar with it. And tired of it. It’d be nice to have a few slightly new and different tests of completely basic competence… but you know what? Any test that is so basic would have to be just as boring. That’s okay.

These tests are essentially saying, “Prove that you’re not lying on your résumé.” And while I may know perfectly well that I’m not lying, how is a total stranger to know that about me? I’m not bothered by the “trust, but verify” stance of modern interviewers, because there are so many people who do lie on their résumés (and fail at simple, FizzBuzz-style tests) that it would be lunacy to blindly believe applicants any more.

(What that says about our society is a topic for another post… a post on another blog. It’s outside Coyote Tracks‘ scope.)

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

In my ongoing job search, I’m sometimes asked by recruiters: “How many years of experience do you have with [name of some technology or skill]?” It’s a somewhat reasonable question when the item involved is a programming language or technique that I use every day, or at least every week. But there are far too many things that it just doesn’t work for.

For example, I can reasonably well say that I have 5 years of experience with AJAX: I taught myself AJAX in the summer of 2005, and have been using it pretty consistently since then. But how many “years of experience” do I have with SQL?

I started using it around 2002 or 2003, but if I say that I “have 7 years of experience” with it, I give the impression that I’m some kind of SQL expert… which is definitely not true. It’s the sort of thing I use about once every week or two. I’ll set up a database schema, maybe even type out some raw commands in a MySQL command-line client, and then I’ll just let whatever framework I’m using handle all the details for me.

So, what sort of answer should I give to the question? The sense in which I “use” (or “have experience with”) SQL is simply not the same as the sense in which I use things like JavaScript, PHP, or CSS. (The sense in which a DBA uses SQL is probably comparable to the sense in which I use CSS… but I can’t be sure, not being one myself.)

At least the idea of having “a year of experience with” SQL does make a certain sort of sense. What should I say when asked how many “years of experience” I have with XML or JSON? These aren’t really “technologies” so much as data formats. It’s like asking someone how many years of experience they have saving files in .txt or .doc format (as opposed to using Notepad or MS Word).

The only metrics that are worse than “years of experience” are: “When did you start using Technology X?” (which, thankfully, very few people have asked), and the utterly subjective “How would you rate yourself with Technology X, on a scale of 1 to 10?” (I need to write an entire post about that particular metric, when I get a chance.)

Originally published at Coyote Tracks. You can comment here or there.

Profile

kai_mactane: (Default)
kai_mactane

July 2011

S M T W T F S
     12
3456789
101112 13141516
17181920212223
24252627282930
31      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 21st, 2017 06:48 am
Powered by Dreamwidth Studios