My secret Hobby: Applying for jobs
irrlicht3d.org
irrlicht3d.org
This. One of the reasons I chose my last employer (SAP, or more specifically, SAP Research) was their no bullshit, yet very thorough, recruitment process.
Compare that with my <A very, very, well known software corp> experience, where the phone call interview with HR went like that:
HR drone: "So, what's your degree?"
Me: "Mathematics." [didn't you read my resume?]
HR: "Oh... well... Most of the people working here have CS degrees."
Me: "Ah, well, my last job title was 'Computer Science researcher' and before that I had several years of experience as a programmer, so I think I'll fit" [apparently not!]
HR: "Yes, but do you know algorithms?"
Me: bangs head on wall
Sorry, no matter how reputable your company is, if that's the recruitment process then I can do better.
I can absolutely guarantee you that the actual hiring manager briefed the HR department on the job spec and had to dumb it down significantly. The summary would have been something along the lines of 'Ideally the perfect candidate will have a CS degree from a major University as strong algorithmic knowledge is a fundamental requirement for the role.'
HR would then interpret this as:
1: Must have CS Degree
2: Must know algorithms.
3: Only CS people study & understand algorithms.
4: Refer to step 1.
Ironically, it helps to think of the HR screening process as a really dumb algorithm. The HR staffer likely has little to no understanding of how to ferret out "knowledge of algorithms," (or any other job skill, for that matter). So he defaults to a list of keywords or phrases -- interpreted very literally -- from a job description received from the hiring manager.
His internal logic is pretty much driven by two directives:
1: If a keyword or phrase is in the job description, a successful applicant MUST have it on his resume. (Word for word, preferably).
2: Anything on a candidate's resume that is not on the job description is irrelevant.
In fairness, there is some legitimate value to the HR screening process. It is a filter. A dumb filter, but a filter that the hiring manager doesn't have time to run on X hundred (or Y thousand) resumes. Some HR filters are designed to screen out resumes that don't contain the right keywords. Others are designed to select for resumes that match all the right keywords. Either way, the effect is similar. Of course, such a process can (and does) weed out a lot of very talented, very qualified people.
The trick is learning how to game the filter. The filter penalizes creative or unusual word choices. The filter flags candidates who reference someone they've met or spoken to at the company (doubly so if that person is the actual referrer). The filter rewards fidelity to the letter of the job description. Tailor your cover letter and resume accordingly.
Some modules are used pretty much all the time (name, address, education, previous jobs and titles). Others are swapped in or out (bullet points under each job, interests if applicable, etc.). I've found that customizing the resume to fit the job is worth the extra 30 minutes of hassle to compile it.
[Note that I do not advocate making shit up. Rather, I've found that sometimes even the same bullet point, phrased two different ways, can have positive or negative outcomes at two different job openings. Or sometimes Job X considers Accomplishment A very important, but Job Y considers A irrelevant. Etc.]
Of course, an army of lawyers put that together - is there an equivalent group to do that for technical resumes? A resume coach at the VFW wouldn't cut it...
My system to date has been very paleolithic. I keep a spreadsheet with all my bullet points, categorized by job and mapped to different Skills and Experiences (i.e., the things to be demonstrated via the bullet points). When compiling a resume, I cross-reference by job description and its keywords, skills/experiences to be shown, etc.
Then I sort of treat the process like a compilation of overlapping sets, i.e., "The job requirements are A, B, and C. I want to show that I've done X, which demonstrates A and B. Then I want to show that I've done Y, which demonstrates B. But maybe Z demonstrates B and C in a more effective way, so I'll use X and Z as my bullets." There is definitely an easier and more automated way to do all this, perhaps with databases, but I still value the organic process of poring over everything myself and gut-checking if the overall narrative flow makes sense.
As you might imagine, I played too many RPGs as a kid.
It's really a cool library; at one point I was going to build a job site to help people build xml-based resumes using this library.
You can output various formats (HTML for web posting, PDF for distribution/printing, .DOC for recruiter's resume-uptake systems (many are based on MS Word / VBA macros). This is also handy for stripping your personal and/or contact information from resumes posted online (to keep annoying contacts down).
Viewed from outside the box: this is a classic example of a clever hack to work around the wrong part of the problem.
Fortunately that tedium is usually brief and infrequent. It's also not current.
And as you said, you want to make sure the overall narrative flow as well as the overall design of the document makes sense for the job.
(I also exploited the ability to link external CSS to make a script that tracked everyone who viewed my resume, with a reverse DNS on their IP.)
How many more tricks will you have to employ after you get past HR to get through the job itself? Let alone have some fun and learn something new.
It might not be an exact science, but it reflects somewhat on existing and future recruits, not to mention an indicator of corporate bureaucracy.
To that point, oftentimes bad HR is really just a scale issue. A company starts getting more resumes than its people can deal with, and so it hires HR drones just to help with the workload. And this continues. Eventually, the managers are so far removed from the day-to-day HR filter that they don't really notice how bad it's become.
Then there's people who've take a slightly different career path, or chosen a job at some unknown place, yet have lots of good experience, and they're ignored because HR doesn't know what to do with them...
I've been that guy on more than one occasion. I'm a self-taught hacker, and I made the mistake of majoring in English in undergrad. While I usually look great on paper at the hiring manager stage, I have pretty spotty luck with the HR filter. To make matters worse, I've graduated twice into very unfortunate circumstances: 1) I graduated from college into a recession (post-tech-bubble-burst); 2) I graduated from grad school into an extremely deep recession.
The necessity of my circumstances has forced me to get creative with my job searches. Hence, the "modular resume" strategy I outlined in a subsequent comment. And hence the general strategy I now take on all job searches. Conventional wisdom holds that a job search is a numbers game: get your name out there as broadly as possible, and eventually, you'll catch a few things in the net. In my case, knowing that I look iffy on paper to HR drones, I know I need higher-touch tactics. Casting a wide net won't get me many fish. I need rod and reel, so to speak.
So I'll hyper-prioritize, say, 10 openings. And then I'll really drill down on them: researching the best fit, reaching out to friends of friends, doing informational interviews, networking over a fairly long term, etc. My goal is to get the hiring manager to know me before my resume hits the HR filter. I'm dead in the water if I hit the HR filter blind. (My affinity for horrible, acquatically themed metaphors knows no limits).
In fairness, a lot of these tactics could be seen as good habits in general. But for me, they were born of necessity. So in some ways, I enjoy being an unconventional candidate. It forces me to experiment, to learn, and to adapt, and to persist.
I ask this because looking for word-for-word matches etc imply a lack of unfamiliarity with the process as viewed from the other side of the table. I understand that you have been a developer previously and probably understand the technical specifics better. But my guess is be that most of these recruiters might have gone the resume-interview route for at least _some_ job; I am surprised that they don't seem to understand how hopeless their techniques are.
So instead of writing something up, the recruiter or manager googles around for "enterprise foobar developer", and copy/pastes a few pidgin english job descriptions from other places.
This arrives in HR, who then needs to translate slop into something that can be posted. Hence, the loop you described above.
"We need someone to do real-time object-oriented programming."
"I do real time. I do object-oriented design and programming."
"But do you do real-time object-oriented programming?"
"Yes."
"I don't believe you."
Their loss, not mine. Employers, listen: Your recruiters come across as idiots when you do this.
To filter out the total idiots, I ask people to give me a one-paragraph answer to one of 5 technical-ish questions. That lets me spend plenty of time on the people that do make it through. I try to reply to all applications personally within 24 hours. Interviews take scheduling priority over pretty much anything else. We meet right after interviewing someone and try to get them an answer either way within a day.
If folks have other things they like (or hate) about hiring processes, I'd love to hear about it. We really want to get this right.
With that, you've addressed my biggest issue with the ordinary hiring process: Complete Lack of Feedback. When I was fresh (or nearly) out of college in 2003, the only responses I received were from the CMU Robotics Lab. And while they were "we're not interested" replies, they at least had a real signature on them. Nothing else I applied for produced even as much as an automated response - print, e-mail, phone, nothing. (My options and interests at the time were admitedly a bit too narrow, and geography worked harshly against me.)
Worse yet is when you interview somewhere and then never hear back. Thankfully that only happened once to me.
Otherwise it really depends on the group and the culture. It doesn't bother me when Megacorps use standardized tests or puzzles (large or popular groups need some sort of advanced filter), but I prefer the hiring process at smaller companies to be more personal.
from my recent job change (several offers). After supposedly reading my resume and after half an hour on the phone the company's staff recruiter asked me to write a paragraph on how i see my fit to the company. It became immediately obvious to me that there is no fit. Somehow that wasn't obvious for him. Next day he's calling and emailing - they really like to talk with me in-house and where is the paragraph? Couple days later - the same. Day after that - they really like to talk with me in-house. The paragraph somehow isn't mentioned anymore. Good luck guys. I hope you find the programmer(s) with a hobby for essay writing.
Anyway, the process of filling a job vacancy is about mutual fit. Somebody, who'd like the process would obviously be a better fit to that company culture than me, so the filter does work.
In my case, it's basically a Turing test. I ask for it along with the resume link. It's just to weed out the obvious dolts. (Who, as somebody else mentioned, are unfortunately 90% of the applicants.) The questions I use are here: http://needfeed.com/about/jobs
I'm pretty sure that anybody would want to hire could toss off an answer to one of those in 5 minutes. Which, given that I'm going to spend 10 or 15 minutes reading their resume, their blog, and (hopefully) their open-source code, seems like a fair trade.
It's a catch-22. Without this process, every man & his dog will apply for the job causing the company to have to filter through literally hundreds of applications in order to find appropriate candidates. Those that actually take the time to tolerate the process obviously consider themselves suitable and do really want the job.
As a Tech Recruiter, I'm generally the front line for job applications and I'll give you stats from my most recent role:
Python Dev- London - Circa £45k
Applications: 48
* 36 highly irrelevant and inappropriate candidates that were blatantly just clicking 'apply' on every job they found.
* 6 applications with no CV attached.
* 6 potentially relevant candidates.
* Out of the 6 potentials that I spoke to over the phone and face to face, only 2 were worth submitting directly to the client.
These stats are pretty much the norm for most of the roles I advertise.
Shouldn't that be the point of tech recruitment agents, though? It used to drive me mad when recruitment agents would phone up, ask for 25%, then email me two "top" CVs which bore zero relevance to the jobs previously advertised.
Out of the 6 potentials that I spoke to over the phone and face to face, only 2 were worth submitting directly to the client.
You sounds like the exception that proves the rule ;)
Absolutely. You engage us to be your personal filter. We shield you from the deluge and provide you access to the handful of suitable candidates. I'm not surprised your recruiters are sending you irrelevant candidates. It's something I ranted about at length in my most recent blog post, link in my profile.
You sounds like the exception that proves the rule ;)
Most recruiters do exactly the same, the difference is the recruiters who actually understand the requirement, your needs & the technology involved will send you some decent CV's from the steaming pile of rubbish they receive, the 'salesman' recruiters will send you two CV's that appear to be relevant or are a high keyword match against the job spec and don't have a fundamental grasp of your needs.
Were you seeing people whose previous job experience was: Receptionist, Typist, Journalist, Janitor, Taxi Driver, etc?
Or were you seeing web developers who never mentioned python on their resume?
The reason I ask is, the majority of the times I've been screened by recruiters, they clearly were unable to tell what was relevant and what was not. EG: Thinking you're not qualified because you worked with a different version of a database the employer uses, even though SQL hasn't changed between versions and you probably usually shouldn't be writing SQL anyway in your code.
The inability to screen properly gave me the distinct impressions that those who were filtering me out were incompetent because they were being arbitrary, and those who weren't filtering me out just had low standards (they didn't ask better questions.) In the end, I was the one who filtered me out of inappropriate jobs because I could tell by their descriptions (if they let me see the job description rather than rambling on about how they need a "ninja coder to take their B2B accounting software to the next level").
Do you use any software to screen the applications for appropriateness? I know that keywords likely would only work to get rid of the 36 (or would they? Did they all say "python" on their resume?) Would machine learning or bayesian techniques possibly work better?
There were a large number of graduates with zero commercial experience and zero open source contributions as well as a number of foreign candidates with completely unrelated careers simply looking for a job in London. There were also a number of underqualified candidates and people with strong careers but zero commercial or practical experience with Python.
- you don't know Python at all
- if you learn it (might be very fast to learn to read it, fast to get into the basics) you're still missing out a lot (Maybe they use IronPython. Or Pypy. You need to learn the eco system: virtualenv et al?)
- even if you mastered that, you still don't know the basic technology they are using (in my sample: Django)
Compare that to a guy that used Python for a couple years. That one only needs to get into your code base and can start working right away.
of course you are right: someone who knows Python well may be better than someone who doesn't.
But if you look at the recruiters experience, who finds only two qualified applications, then I say: find a good programmer among the applicants who really wants to get into Python and you will get someone who comes to speed very quickly.
You might even find someone who is enthusiastic about his new job, instead of someone who does the same thing since 1996, who is good at what he does, but a bit bored too.
These recruiters always think in their own minds cage: according to them, you start something once, and do it for the rest of your life, because nobody will let you do something different. Most software developers are much too smart for that cage only.
A large percentage of the population here falls in that category, but we aren't representative of the industry as a whole. What do you think a Blub programmer actually is?
I think once you've learned enough languages, they become like lenses on a camera. You're as good a photographer as you are, whether you use one lens or a different lens.
The lens doesn't make a bad photographer good, and a good photographer will be just as good using a lens they've never used before, given a short period of time to familiarize themselves with it.
The environment of a particular job you always have to learn, even if you've used the exact tools at a previous job.
After a year, it is the strength of the photographer or programmer that is going to determine how much and how good their work is, not whether they knew the tool before they took the job.
Very good reply and also a very good metaphor.
The outsourcing went ahead anyway.
The US based staff would get grief if the projects weren't completed on time or had issues.
I don't blame the Indian lads, they were getting paid crap. Also, many of them weren't great, as the pay was crap and good programmers in India wouldn't work for the company.
In my career I've dealt with quite a few people like this, both as a hiring manager and as a candidate. As a hiring manager you get the opportunity to ask them some detailed questions about how they filter candidates, and I even asked one, once, to send me all of the resumes they got for the position, after she'd applied her filter. I went thru the entire stack of resumes myself, and filtered them by looking at them briefly, and then compared the ones I pulled out to hers. There was zero correlation. None of the ones I pulled out she did. All of the ones she pulled out -- and was busy giving me the hard sell on-- were ones I'd excluded. In fact my belief that the pickings couldn't be so slim was the reason I asked her to send me all of them, though I gave her some other excuse at the time. I also pulled twice as many candidates as she did, and was willing to spend up to an hour of my own time on the phone with them.
All of the people in your position think they know what they are doing and think they are good at being able to tell good candidates from bad ones. I understand why this might be, as this seems to be what they think is their job. "Anybody can exclude the janitors-- but I add value by being able to tell good programmers from bad ones!"
If you'd like to be a better recruiter, here's some changes to make:
1. Stop reviewing people's code. I've participated in many code reviews. I've often seen stuff that looked stupid, and asked the programmer about it, and then found out that they were expressing a level of understanding of the problem that was stronger than mine. Makes sense given that it wasn't my code I was reviewing, I was just reviewing, not writing it. That you think you can review someones contributions to open source in isolation is a big red flag. Just stop. Even if you're a great programmer, you can't do it fairly. In fact, if you were good enough to do it, you wouldn't want to do it because you'd know how easily it is to get wrong.
2. Just because someone doesn't list python on their resume, does not mean they wouldn't be a great python programmer. I've been using python off and on since the mid 1990s. I use it for utilities, tools and other support code, not for major projects, and it turns out (I just checked) I never actually put it on my resume. By your statements above I would have a "strong career but zero commercial or practical experience with python".
3. Just because someone has never programmed in python before, does not mean can't be the best candidate for the job. Programming is the talent. Python is a language. If you would say I'm unqualified to drive a ford because I've been driving toyotas, you'd be laughed at, wouldn't you? This is what you're doing. Every language has its strengths and weaknesses, sure. Unless you're hiring someone for a 3-5 week job, the quality of python code produced in the 6th week will have everything to do with the strength of the programmer, and nothing to do with the amount of python they've used in the past.
4. I once was interviewed by a recruiter and it became immediately obvious he was something special. I could tell he wasn't technical, so after he said he'd be setting up an interview with the hiring manager, I asked him how he'd come to the decision. He gave me a solution that you, and every non-technical person can apply, which is really quite brilliant: He said (paraphrasing) "I look for three things: ABC: Attitude, Bandwidth and Confidence. If they have a positive attitude, can explain things well to show they have a bright mind, and have some confidence, then I ask them a follow up question. I ask them to tell me about some technical thing they did that they're proud of. If my eyes glaze over, I know they are qualified to pass on." He didn't have to understand what the thing was, but he was uncanny in finding great candidates... in large part because his reputation caused them to seek him out. Maybe someone could bullshit him with a bunch of technical jargon that he didn't understand, that's fine, that's not his job. The idea of him judging my code is absurd, and would be to him too.
Please take this in the spirit it is intended, which is constructively.
It's difficult given the immense air of condescension.
1: Stop reviewing peoples code: You may want to have a chat with some of the countries top programmers & hiring managers. Almost all of my clients insist on seeing examples of the candidates code before interviewing them. I review the code first myself to ensure I am sending someone worthwhile.
2: Just because someone doesn't list python on their resume, does not mean they wouldn't be a great python programmer: If you have the wealth of Python experience you are claiming and were applying for a Python Dev role would you really not alter your CV to reflect your relevance for the role? That would be lazy and counter-productive giving an instant indication of your attitude.
3: Just because someone has never programmed in python before, does not mean can't be the best candidate for the job. If you would say I'm unqualified to drive a ford because I've been driving toyotas, you'd be laughed at, wouldn't you? That is a ridiculous analogy. There is absolutely zero difference in the machinations of driving a Ford over a Toyota whereas there is a significantly larger learning curve for someone making the switch from PHP to Python. Couple that with the fact that if a Techinical Director insists that candidates have commercial experience in a particular language as their current workload doesn't afford them the opportunity to wait for someone to come up to speed then I am going to insist on commercial experience in that particular language. A more appropriate analogy: Would you let a lawnmower mechanic rebuild the engine on your Ferrari?
4: ABC: Attitude, Bandwidth and Confidence: Typical, sales jargon. You can have the greatest attitude in the world, that doesn't imply that you are going to be a great programmer. In fact, I find the majority of highly skilled programmers are inherently introvert and humble.
I appreciate your intention is to provide an alternative perspective but the bottom line is this: I am very good at what I do. I have developed a significant reputation in the real world as well as here on HN as being a recruiter who takes a different approach to the business and my clients continue to come back to me as I consistently send them top quality candidates. I know what I'm doing & if I were to apply your advice I would be undoing a lot of the great work I have accomplished to date. My advice to you would be to stick to doing what you do best and leave me to continue doing what I do best.
You probably missed out on some decent candidates with that as knowing how to program is often not limited to a specific language. Programming is more a way of thinking and approaching problems than knowing a specific syntax.
When filling a role for a C#/ASP.NET web developer the person we chose to hire had ZERO C#/ASP.NET experience, but had many years of Java experience making the same type of applications we needed. He got up to speed extremely quickly and was a great contributor to the team.
This kind of ignorance is why you should never use a "Tech Recruiter" to hire your technical candidates --- even the ones savvy enough to post on Hacker News seem to value programming-language knowledge you can pick up in two weeks over "strong careers".
If you sincerely believe that after two weeks, even two months, you would be as strong a Python Dev as someone who has been applying their Python knowledge in various commercial projects consistently for the last four years then you may need a significant dose of humility.
So why do I think I'd be a better C# programmer than most C# programmers in only two weeks? Because I'm a better programmer than most of them, and that's a more significant factor than language and library knowledge. A mediocre programmer can be mediocre in any language, and many of them continue to be mediocre for many years. Also, when you join an existing team with experience in a language, you can draw on their expertise.
There are a lot of programmers who are better than I am, thousands if not tens of thousands of them. I've had the privilege of collaborating with some of them. If someone had to choose between me and someone else at about my level, they'd be entirely justified in making the decision based on language knowledge. But the vast majority of experienced programmers are worse than I am --- much worse.
But let me tell you first hand (I'm trying to hire a PHP developer now), you get lots of truly and objectively bad candidates. People who want to telecommute even though the job clearly says you must be on-site. Or people who submit a resume that does not demonstrate the required skills and do not include a cover letter.
I've found that some University job boards make it way too easy for a student to check off a whole bunch of jobs (or perhaps all the jobs) and apply to them en masse.
Your commenting history suggests you might have a clue what you're doing, but this comment taken by itself could easily be from a recruiter that's part of the problem and doesn't know it. Lord knows I've never (in the US) personally encountered a recruiter that really understood the position they were trying to fill.
I'm a former developer. I'm currently teaching myself Python. I listen and understand my clients needs. I'm not afraid to ask a client or candidate to elaborate on a point I don't understand. Essentially I don't think that it's necessary for a recruiter to claim to know everything about every technology as I believe from experience that a lot of employers find honesty refreshing.
- they have a github profile - they have a stackoverflow profile - they have a linkedin profile
(the latter will go for a CV - I actually used it when one $reasonably_big_and_known_company called me up wanting to hire me and wanted me to write a CV - I told them to use my linkedin profile, and it worked all right).
Arguably this is not a 1:1 relation - since there might be a lot of good programmers that do not bother to communicate much externally.
But if they have the presence, then you will be well able to judge their quality without having to ask them a single question. (I silently assume you can read code/judge programming questions - if not, then my blurb is of not much use indeed)
"Know, my friends, when I was no more than eight years old, I had already cultivated the remarkable habit of telling one really big lie per year".
I wonder if these hobbies could be combined? Indulging in these kind of pranks seems almost justifiable given the "can they really be serious" shenanigans perpetrated upon those of our trade by the interviewers and recruiters.
I am polishing my resume, with special emphasis on my glory days at the Austrian Naval Academy.
a) If somewhere offers you a lot money, you can take that back to your current employer. I've had a 30% payrise from that before on my day rate.
b) Slightly bigger companies with big pockets are often hiring 'unofficially'. That means if they know you and like you, they're often willing to employ you. If you've applied for a job, but turned it down while being very very positive about the company, you've got a set of contacts there to email when you current contract doesn't get renewed...
Let's say the unqualified outnumber the qualified by 5 to 1. They're also job-searching on company time, so they send out 5 times as many resumes as the qualified. Their resumes then outnumber the qualified by 25 to 1. This gives you the ratios that Peroni sees.
What's hard - very hard - is that good engineers aren't great at writing job descriptions that are useful to HR recruiters. Conversely, many good HR recruiters still don't understand technical job descriptions.
In the end, this is why the best recruiting method still seems to be, "Ask your best person who their most capable friend is."
I have so little time to myself that I can't spend hours solving each little puzzle a HR department comes up with...
That same system was implemented on the company's website later on, which didn't make me feel any better. To top it all off, they never even replied.
B) How do you know they programmed that app with thousands of users even remotely well? Did they store passwords in plaintext? Does it need to be reboot every 5 mins? Is it slow as molasses, but hidden behind load balancing?
Someone could have written awesome sites with 1000s of users and loads of revenue, but it might still have been done like crap, and doesn't belong anywhere on your network.
B) I ask them questions about the implementation.
You can get a feel for whether the candidate can program a simple blog by asking them how they'd do it, you don't have to ask them to spend hours actually doing the nitty-gritty...
When I hire, I do a phone screen before asking the candidates to complete the code exercise. If it isn't going to be a fit from either of our perspectives, then they didn't spend time doing it.
The biggest plus for me as the hiring manager is that it allows me to be much more confident in taking flyers on people without that picture perfect resume.
I have a major open source project under my belt, but I've never had an interviewer simply ask me about my code. Instead, they ask me to sort an array.
In regards to discussing existing code, I'd be more than happy to do so, but my experience has been that about one person per stack of resumes has quality existing code available to share.
"Time I'm willing to dedicate to your interview problems" and "time I'm willing to dedicate to reading and writing on HN" are not freely interchangeable; you can (and presumably do) have radically different expectations of the costs and benefits that make them incomparable.
Most recently I asked a candidate to work a few hours on a real project for a fair hourly rate. I think this is much better for all involved. As a bonus, you get to see how they perform on a real project, rather than a contrived puzzle and they get to see what sort of work they might be doing if hired.
Paying people for a few hours of work is difficult: if we pay them as an employee then we have to do employee paperwork and deal with the payroll company. If we pay them as a contractor then they have to sign a lot of contractor paperwork, including a confidentiality and intellectual property assignment agreement. It's the kind of thing I wouldn't sign without my lawyer's advice. It just seems like too much trouble.
Instead, we'll either work on a throwaway toy project or an open-source project. Both of those are working well so far, and people seem happy to actually ship some open-source code at the end of the interview.
Bravo.
I can't stand when companies do this. Whether it's design or development, it's basically spec work. It's one thing if it's a general question, but if they ask you to do work related to their service, why not just pay them for a few hours or a few days?
It was like filling up a visa application.
Like a poster mentioned elsewhere: the interview process is also a strong indicator of the internal atmosphere, too. I don't want to work for any company which believes such a form is a good idea.
We are always completely upfront about it though.
Interviewer: "Do you know X?"
Me: "Yes"
Interviewer: "Great, do you know Y?"
Me: "Sure" (starting to get suspicious)
Interviewer: "Nice, how about Z?"
Me: "Aha" (not believing this)
Interviewer: "When can you start?"
....
This is the opposite side of the coin. This quick-fire hiring is scary and detrimental. What would that tell you about the company? :)
I am a human resources manager, and I like to call people in for interview.
We do not have any openings but I just like to call them, give them 1-2 tests, make them sweat, then never call them again.
It is more fun than going at the interview, you should give it a shot. :) Daniel - 10 08 11 - 13:10
Needless to say, I never referred any of my friends.
They know they are going to promote the guy already at their company, but they are bound to do a full search anyway.
This doesn't sound frequent enough to really extrapolate anything about trends. Maybe he meant once a month?
My theory is that if every company does this, then the current body of employees will work harder to stay out of that prison of unemployment, where everyone kicks you when you are down. I am in support of all the good programmers everywhere applying to jobs without intending to take them, and generally treating the system that hires you like crap. So next time you are unemployed and you are treated badly, you'll at least know why they are doing so.