In the semi-mythological days of yore, it used to be the case that you’d get hired at some company and you’d have a reasonable expectation that there’d be a job for you there for as long as you’d like. If your skills were out of line with what was going on in the company, they’d retrain you. No big deal.
In the 1990s, the process of putting a PC on everyone’s desk began, and companies large and small trained people to use them. For a few years there was a question as to whether personal computers really added to worker productivity or whether they represented an expensive desk decoration, but then the Web came along and caused new businesses and products to be created every day, and people stopped asking those questions — the gain in productivity became obvious.
But then two things started happening: a lot of companies pulled back on their training investments (perhaps thinking that once all employees understood how to print in landscape mode in Microsoft Word, there was nothing new to teach them). At the same time, the job interview process started getting weird. You’d hear a lot about torturous “puzzle questions” being asked in interviews (many of which were immortalized in the book “How Would You Move Mount Fuji?” which covered the Microsoft process specifically.
Not every company treats the technical interview as mortal combat, but it’s definitely the case that the main (and, sometimes, only) venue in which a employer can ascertain the skills of a prospective hire is in the interview room. So it may be natural that the instinct is to savage the prospective hire (after all, this is just some person off the street at this point, it’s not like she actually works for you yet) to see how they hold up.
The message here is clear — employers want the people they hire to be “plug and play”. New hires should understand the practices and technologies in use at the company before they’re hired, so that the company doesn’t have to bear the expense of training them (and, after that’s done, dealing with what happens if training doesn’t take).
This always struck me as a little backward, since very little of what a technical professional does on the job bears any resemblance to what goes on in an interview. It also sets an adversarial tone between the employer and job seeker from day one that isn’t ideal for anybody.
I’ve interviewed many, many coders over the years. (As a teenager, one of my first summer jobs was at a tech staffing firm, screening job seekers and placing cold calls to hiring managers.) So I’ve spent literally decades mulling over the bogosity of the tech interview, but I could never really think of a good alternative to the interview format that wouldn’t either 1) create a huge time suck for everybody or 2) be really unfair to the job seeker (like making jobs contract-to-permanent).
Today I had an epiphany. Maybe the right thing to do is to enroll prospective job applicants in some kind of low-impact training as part of the interview process. If the training were given in a part-time, online format (like we do at CodeLesson), the time commitment could be minimal on the employer’s part (the instructor role could also be outsourced) and it wouldn’t take time away from the prospective hire’s job hunt. The learning experience could be a net positive for the job seeker, too, because instead of burning time meeting with one dead-eyed middle manager after another getting asked the same questions, she has the potential to emerge from the process with a new skill.
No comments:
Post a Comment