"Don't ask me where I want to be in 5 years...If you want to know if I want to pursue tech vs management, just ask that."
I agree. Not that I don't have any long-term goals at the moment, but I expect life to change and I usually flex with those changes so who knows where I'll be in five years?
I've been firmly freelance the past few years, but occasionally look in to the 'job' world (not being derogatory there). I've gone through a few interviews, and I'm amazed at how poorly people usually do it. I'm also amazed at how differently some places treat interviewing for a fulltime job vs interviewing for a 6 month contract. My own experience is that the people talking to you about a fulltime gig may drill you pretty hard on rather trivial stuff, but if you're coming in for a short term contract, or in a consulting role, there's often little vetting - there's an assumption that you already know stuff. Very odd, imo.
Sometimes I feel a bit insulted if they don't do some background checking. I'm not a superstar well-known name, but I do have a unique name - there's only 2 of me in the world that I know of, and one is my uncle :) I've published open source code, I've run a blog (a lot of tech on it) for a number of years, run a web-development podcast, spoken at numerous web/tech conferences, as well as other stuff. Googling my name brings up loads of stuff about me and what I've done. Yet given all that, I'll talk to an interviewer (after someone's already reached out to me based on what they've allegedly found) and I'll get "so, tell me what you've done" or "what's your involvement in the community?". Good Lord, it's all there - 20 seconds before a phone screen would yield loads of info. I go to the trouble of learning what I can about company X, yet the courtesy is rarely returned.
Hint, recruiters - I have a note to recruiters on my main site. If you mention that you've read it when you reach out to me, you'll get my undivided attention simply because you bothered to read it.
Loads of 'old school' interviewing stuff was drilled in to me years ago - be polite, on time, courteous, do research on the other party, express interest, ask insightful questions, etc. If the other party doesn't show the same basic behaviours, goodbye.
I struggle with this because there's time when I feel like I'm just looking for an ego-stroke (as my wife has said). But at the same time, I've put time and effort in to my craft, skills, and presentation of same, just like Company X has put in to their org, website, team, etc. If you expect me to know your company and be excited about working with you, research me and be excited about me. Few companies bother taking this approach, then complain that they can't find workers. :/
they could be so much more effective in my experience.
Amen! I can count on one hand the number of recruiters that I'd recommend to either a company or someone looking for work.
As an industry, they must be being 'effective enough' because they're still doing it. I'm waiting for a disruptor to hit that market and radically change the way things are done. It'd be huge.
"All the jobs are in New York or the San Francisco Bay Area.
If you're looking to work elsewhere, we can't help you right now. Sorry!"
It's great to have focus, but there's a much larger group of developers out there who A) don't live in those areas, B) don't/can't move to those areas and C) don't want to work at a 'startup'.
Hackruiter looks neat, but I don't think it's 'disruption' in the sense I was talking about. It's catering to a very small niche of people who are risk-takers and probably "off the beaten path" anyway.
I couldn't reply directly to you, so had to do it one level above!
This has been on my mind for some time (years), but as with many things, it's little more than an idea. But I have many other ideas which are equally compelling, and I'm pursuing yet other compelling ideas right now too.
Just because someone sees an opportunity in a market doesn't necessarily mean that they're the best equipped (or equipped at all) to actually tackle it.
It's like real estate. Recruiting looks like easy money, so it attracts many, many entrants. Only a few are successful enough to stick to it as a full-time job.
The incentives don't make sense. As a realtor, you get a huge, immediate payoff when the house sells. You don't care about the price.
Recruiters are worse. As a recruiter, you get a huge, immediate payoff when your client hires any candidate at any price. You don't actually care how good the fit is, so the rational behaviour is to spray as many candidates at as many clients as possible.
"As a realtor, you get a huge, immediate payoff when the house sells."
"immediate", except for the fact that you might have been working to find or sell the house for a year, and months to put the deal together.
This is assuming the house ever does sell at all, and you haven't worked for months or years to get absolutely nothing.
And it assumes that if the house sells you don't get cheated by your client and actually do get paid.
"You don't care about the price."
Except that usually real estate agents get a percentage of the sale price as commission.
Real estate agents also want to make their client happy so that they'll get recommendations and referrals from them in the future, and want to work with that agent again when they look to buy or sell another home.
Exactly, they get a percentage of the sale price as a commission.
1% of a $300,000 house is $3,000.
1% of a $325,000 house is $3,250.
The realtor has $250 to gain from holding your house price as high as possible, increasing the amount of work he has to do. He has $3,000 on the line to sell it at the lower price, with less work.
The rational behaviour is to sell as fast as possible, and damn the price.
I think it's like real estate agents. It's possible to luck into a payday even if you do a poor job because the quality of the product being purchased is divorced from the quality of the service you provide - luck into showing the right job to the right person, and you get paid, even if you didn't add any other value anywhere. So you can either try to do a good job of matching people and jobs, or else just shoot for numbers and try to match a lot of people and jobs.
I've recently been doing a job search, and I've had one recruiter who I felt really helped me do a better job searching for jobs. I've had five do zero-value-added resume forwarding. One more who is somewhere in between. And two dozen who didn't even read my geographic or full-time preferences who have received quick nos. The part that really bugs me is I actually like one of the jobs from the zero-value-added resume forwarding, so a poor recruiter might end up getting paid through sheer luck and numbers.
> I understand that C is the "lingua franca" of interviews, but if you read my resume (or even talked to me) you'd know I'm not looking for a C job (and really haven't used C since college). While, I'm open to coding in C, it's cooler if you don't force me to use C.
The article assumes that the reason someone would ask them to use C on an interview is because it's lingua franca, and they're only interested in the interviewee's algorithm knowledge.
Algorithms are great and should be a part of an interview, but I am interviewing software engineers, not algorists: I'll ask about general algorithms (the ones you might find in first half of "Algorithm Design Manual" and in "Programming Pearls"), data structures (where I'll expect the interviewee to understand pointers: whether in a language like Python or Java, where every value (with exception of Java's primitives) is a pointer or in a language like C where pointers are explicit).
I'll also ask about algorithms specific to their job, or (if I am interviewing a candidate for another project, as a part of a panel) I'll leave that to other interviewers. If, for example, somebody lists ten years of distributed systems development they should be familiar with the various consensus algorithms, pros and cons of them (I will not expect them to implement Paxos, but it would be nice if they know how multi-Paxos and ZAB solve some of the issues Lamport's original algorithm had). Again, this is for experienced candidates being interviewed for a role in which they claim existing experience.
There are also simple algorithms (related to string or array manipulation) that are just easier implemented in C. If ask someone to reverse a string in place [NB: I don't actually ask this], they'd have an easier time doing it in C than in Java.
However, there's more to C than a language in which to implement algorithms: it's also a systems language. I want candidates I hire to understand how their computers work. I'll challenge them to understand how various system calls work, how parts of libc are implemented, how memory allocation works (and, if I am interviewing a candidate for a Java, Python et all collection how garbage collection works, and in what cases might it fail to work). In this case, knowing C (and having it used it, at least in your own free time after college) is invaluable, not because of the language itself-- but because it's a great portable assembler.
I understand people are frustrated when they're expected to know C, even though they won't be programming in it: however, it's not about the language, it's about knowing about an area of computer science that isn't often as glamorous, but is just as crucial as algorithms and data structures.
I'm not completely convinced that programming in C in an hour long interview is the most productive way of testing system call, libc and garbage collection knowledge.
I do agree if you are applying for a systems level job, C testing should be more rigorous.
You don't have to answer every single question in C. It's just that you're going to be much more likely understand a question e.g., "how do free() and malloc() work" if you know C. You also don't want to be asking difficult questions for the entire hour: I always prefer to let the candidate introduce themselves, warm them up with an easier question (to help make the candidate less nervous), add a challenging twist to the easy question, and then asks the most challenging questions.
Understanding systems matters for more than systems levels jobs: perhaps you don't need it if you plan to work on CRUD apps in a financial organization, but if technological aptitude is an enabling factor for a company you're applying to (that's the case for companies in Silicon Valley: otherwise there's no point to being in the most expensive part of the country), you should understand more than your segment of the stack (that goes both ways: systems programmers should still understand HTTP and high level languages if they work in a web services company).
I've found it helpful when interviewing and it's becoming obvious the interviewee "really needs to hit Google" that you just say, "Just write the function down with some appropriate parameters and keep going". For instance, it's easy to have year and years of very detailed experience in a language, yet still not quite remember off the top of your head how to open a file and read some lines out of it, which turns out to be something that you do far less often than you might think, because it's often totally abstracted away. If you haven't got any clue what to do with a string, on the other hand, that's probably a problem.
You still get what you need as an interviewer; even if you don't know the parameters, you should still see basic error checking, you can learn a lot if they don't provide the correct parameters, etc. This approach also allows you to implement the "don't know the language" interview; I don't really know PHP but I've interviewed people in it, because I know it well enough to see the things I am looking for. In that case I don't even know the precise parameters to open to "nail you" on them in the first place! But that's not what I'm looking for.
The interesting thing is there are some people who on paper come across as strong, but throw a simple programming problem at them and they give you a blank stare.
I'm usually not playing the compiler type during the interview. Pseudo code would probably work since I want to see problem solving. (But those who could write pseudo code could just as easily substitute in their language de jour).
Lets look at the "Ideal interview" examples, it doesn't look like any of those involved asking technical questions (e.g. coding on the whiteboard)?
The trouble is that unless someone is highly referred from a technical coworker you trust, it's going to be hard to know in advance if you have the technical chops or not.
Anyone can write down on their resume they've done A, B, C and are well-versed in X, Y, Z. They might even be able to talk the talk. But when it comes to writing code they might completely freeze or write something that would make college students blush.
Finally, the time is limited (could be 45 mins, could be 1 hour) during the interview, and the most important thing in most peoples minds is technical chops. That's why I'll usually start out with that (unless the candidate was referred or seems highly qualified, in which case I'll merely get into that later), since it could just weed out the candidate before getting very far.
With your regard of "Convince me why I want to work at your company," I think that only happens once a candidate has proven to be worthy. At least in my last company we would be in "sell" or "buy" mode for a candidate (sell meaning we try to convince him/her to join, buy meaning we try to convince ourselves if he/she should join) and it would start out in buy mode.
There's nothing worse than interviewing and hiring a candidate with a great personality than just finding out he/she couldn't code their way out of a paper bag. That being said, I do dislike interviews where they spend the entire time just asking technical questions as it should be obvious after one or two, so a particular balance needs to be sought.
Where did I advocate not asking technical questions? In the ideal situation, you've already looked at my code, and know the work I've done from the recommendation. (Note I said "highly recommended").
WRT convincing. Sure you start off in buy, since you're hiring. But you should be open to the thought that a great candidate probably has other great options on the table, and they need to vet those out. Ideally you would provide them that opportunity.
Right, as you said the technical question is unnecessary if they've already looked at the code. Which would be pretty hard unless the candidate kept his/her code up somewhere (linked from the resume) or had former coworkers essentially vouch for his/her code quality.
And even if the candidate does have the code up, not all interviewers would bother spending the time to look at it. At the end of the day I think it is based off some kind of reputation on whether or not people believe in the technical chops enough to skip asking the candidate the question.
And it's really hard to draw the line between belief and sloppy interviewing where they simply forget to ask.
I wonder, in your cases where you experienced the ideal interview, which factors do you think contributed to it?
I'm trying to become a better interviewer, and it can be very hard. Here's a story of a badly wasted phone screen I did this week. I screened a guy with a graduate degree in math who worked in a network analysis group for a telco. We talked about the current project he was working on, and his previous project, and while it was really cool statistical modeling of network failure and recovery, he didn't actually do any of the modeling or mathematical work. As best as I could tell, he just wrote scripts to munge data into convenient formats for his teammates to import into the modeling software. He knew next to nothing about statistical software. I described what we did and asked him what kind of work he thought he could do for us, and he basically said he'd do network modeling and analysis for us -- exactly what he wasn't doing at his current job, it seemed.
Afterwards I told my boss, "This guy is a total miss. He just writes Perl scripts to munge log files. Why did we even talk to him?"
"Oh, he's a really sophisticated low-level network performance guy. He has a lot of hands-on knowledge of networking hardware and protocols."
Well... shit. I guess munging log files can be more than just munging log files. I couldn't tell that from his resume, though, and he didn't give me any clue while he was talking to me. Was that my fault?
If you didn't decide to interview him, or set it up, you should have asked the person who did (in this case, your boss) what it was about the person that caught their attention in the first place. Why did your boss think this was worth pursuing? With that knowledge in place, it would help shape your questions.
Also tell me why.. and don't have your administrative assistant make the call. YOU (the person who interviewed me) call me. Tell me what you liked and what you didn't. I took a few hours out of my day to come talk to you, give me some honest feedback here.
The OP wasn't asking for a loveletter—he just wants always to receive a confirmation of the "no" answers after they have been made. It's not much to ask.
I can understand why you might want that, but I'm sorry, that's insane from the other side. While this is by no means the only reason this can't work, it is enough: Telling you directly why we passed is an invitation to get into a very heated argument about how that's not true and how it was misunderstood and how unfair the whole thing is. And there's still the legal reasons, and a number of other human reasons; I could go on for a while on how bad an idea this is. It can't happen this way.
Much as we would like it, they can't. This came up in another HN thread a few months ago. The problem is that if they say the wrong thing regarding your rejection, you might be able to hold them legally liable, pull some kind of discrimination suit.
Sometimes it is your personality; some employers are trying to build a team, and it takes a combo of skills AND group fit.
And ultimately, their answer would probably not be very helpful. Are you looking to improve or to find a way to cope/rationalize with the rejection? If you are honestly looking to improve, all they can tell you is how you might improve for them. What is the expected next step? Apply again? Complain about how they should give you a second look? Nah, it is probably go elsewhere and hope a different company shares the same opinions on how to hire people so that your newfound knowledge is useful.
I am not saying I disagree with the sentiment. It is just as helpful as flicking off a stranger on the road. Makes you feel good. Doesn't land you a job. No doubt there are a few anecdotes to the contrary, as there are always exceptions, but the legal and subjective aspects can erupt into some ugly encounters nobody really wants. Just the fear of that is enough.
I not asking them to tell me why ... just that I didn't make the cut. Believe it or not, some companies won't call you to say they're not going to pick you ... they expect you to figure it out.
One of the most annoying forms of interview has to be the immediately technical phone screen. I remember talking with startups, and during the initial phone call they'd leap into a canned set of technical screening questions, which themselves are some set of factoids which are supposed to translate to how good of a programmer you are.
I understand the need for startups to screen out absolute idiots before they spend time talking with a candidate; it's easy enough, though, to look the guy up beforehand or send the guy a coding question he could work on in isolation. Just make it a policy to only talk to candidates that have something technical you can verify beforehand.
In our current tech job market, it makes sense for the company to convince you it makes sense to talk to them further; chances are, if you're any good and someone they want, you can and will get multiple offers anyway. Even if the company wastes "talk time" to candidates that wouldn't make the cut, it's worth not driving away the guys who got annoyed by its strong-hand "we need a strong code monkey" interviewing tactics.
34 comments
[ 2.7 ms ] story [ 94.1 ms ] threadI agree. Not that I don't have any long-term goals at the moment, but I expect life to change and I usually flex with those changes so who knows where I'll be in five years?
Sometimes I feel a bit insulted if they don't do some background checking. I'm not a superstar well-known name, but I do have a unique name - there's only 2 of me in the world that I know of, and one is my uncle :) I've published open source code, I've run a blog (a lot of tech on it) for a number of years, run a web-development podcast, spoken at numerous web/tech conferences, as well as other stuff. Googling my name brings up loads of stuff about me and what I've done. Yet given all that, I'll talk to an interviewer (after someone's already reached out to me based on what they've allegedly found) and I'll get "so, tell me what you've done" or "what's your involvement in the community?". Good Lord, it's all there - 20 seconds before a phone screen would yield loads of info. I go to the trouble of learning what I can about company X, yet the courtesy is rarely returned.
Hint, recruiters - I have a note to recruiters on my main site. If you mention that you've read it when you reach out to me, you'll get my undivided attention simply because you bothered to read it.
Loads of 'old school' interviewing stuff was drilled in to me years ago - be polite, on time, courteous, do research on the other party, express interest, ask insightful questions, etc. If the other party doesn't show the same basic behaviours, goodbye.
I struggle with this because there's time when I feel like I'm just looking for an ego-stroke (as my wife has said). But at the same time, I've put time and effort in to my craft, skills, and presentation of same, just like Company X has put in to their org, website, team, etc. If you expect me to know your company and be excited about working with you, research me and be excited about me. Few companies bother taking this approach, then complain that they can't find workers. :/
Don't get me started on recruiters ... they could be so much more effective in my experience.
Amen! I can count on one hand the number of recruiters that I'd recommend to either a company or someone looking for work.
As an industry, they must be being 'effective enough' because they're still doing it. I'm waiting for a disruptor to hit that market and radically change the way things are done. It'd be huge.
Neat idea, but
"All the jobs are in New York or the San Francisco Bay Area. If you're looking to work elsewhere, we can't help you right now. Sorry!"
It's great to have focus, but there's a much larger group of developers out there who A) don't live in those areas, B) don't/can't move to those areas and C) don't want to work at a 'startup'.
Hackruiter looks neat, but I don't think it's 'disruption' in the sense I was talking about. It's catering to a very small niche of people who are risk-takers and probably "off the beaten path" anyway.
I couldn't reply directly to you, so had to do it one level above!
This has been on my mind for some time (years), but as with many things, it's little more than an idea. But I have many other ideas which are equally compelling, and I'm pursuing yet other compelling ideas right now too.
Just because someone sees an opportunity in a market doesn't necessarily mean that they're the best equipped (or equipped at all) to actually tackle it.
But thanks for the public push all the same.
The incentives don't make sense. As a realtor, you get a huge, immediate payoff when the house sells. You don't care about the price.
Recruiters are worse. As a recruiter, you get a huge, immediate payoff when your client hires any candidate at any price. You don't actually care how good the fit is, so the rational behaviour is to spray as many candidates at as many clients as possible.
"immediate", except for the fact that you might have been working to find or sell the house for a year, and months to put the deal together.
This is assuming the house ever does sell at all, and you haven't worked for months or years to get absolutely nothing.
And it assumes that if the house sells you don't get cheated by your client and actually do get paid.
"You don't care about the price."
Except that usually real estate agents get a percentage of the sale price as commission.
Real estate agents also want to make their client happy so that they'll get recommendations and referrals from them in the future, and want to work with that agent again when they look to buy or sell another home.
1% of a $300,000 house is $3,000. 1% of a $325,000 house is $3,250.
The realtor has $250 to gain from holding your house price as high as possible, increasing the amount of work he has to do. He has $3,000 on the line to sell it at the lower price, with less work.
The rational behaviour is to sell as fast as possible, and damn the price.
I've recently been doing a job search, and I've had one recruiter who I felt really helped me do a better job searching for jobs. I've had five do zero-value-added resume forwarding. One more who is somewhere in between. And two dozen who didn't even read my geographic or full-time preferences who have received quick nos. The part that really bugs me is I actually like one of the jobs from the zero-value-added resume forwarding, so a poor recruiter might end up getting paid through sheer luck and numbers.
The article assumes that the reason someone would ask them to use C on an interview is because it's lingua franca, and they're only interested in the interviewee's algorithm knowledge.
Algorithms are great and should be a part of an interview, but I am interviewing software engineers, not algorists: I'll ask about general algorithms (the ones you might find in first half of "Algorithm Design Manual" and in "Programming Pearls"), data structures (where I'll expect the interviewee to understand pointers: whether in a language like Python or Java, where every value (with exception of Java's primitives) is a pointer or in a language like C where pointers are explicit).
I'll also ask about algorithms specific to their job, or (if I am interviewing a candidate for another project, as a part of a panel) I'll leave that to other interviewers. If, for example, somebody lists ten years of distributed systems development they should be familiar with the various consensus algorithms, pros and cons of them (I will not expect them to implement Paxos, but it would be nice if they know how multi-Paxos and ZAB solve some of the issues Lamport's original algorithm had). Again, this is for experienced candidates being interviewed for a role in which they claim existing experience.
There are also simple algorithms (related to string or array manipulation) that are just easier implemented in C. If ask someone to reverse a string in place [NB: I don't actually ask this], they'd have an easier time doing it in C than in Java.
However, there's more to C than a language in which to implement algorithms: it's also a systems language. I want candidates I hire to understand how their computers work. I'll challenge them to understand how various system calls work, how parts of libc are implemented, how memory allocation works (and, if I am interviewing a candidate for a Java, Python et all collection how garbage collection works, and in what cases might it fail to work). In this case, knowing C (and having it used it, at least in your own free time after college) is invaluable, not because of the language itself-- but because it's a great portable assembler.
I understand people are frustrated when they're expected to know C, even though they won't be programming in it: however, it's not about the language, it's about knowing about an area of computer science that isn't often as glamorous, but is just as crucial as algorithms and data structures.
I do agree if you are applying for a systems level job, C testing should be more rigorous.
Understanding systems matters for more than systems levels jobs: perhaps you don't need it if you plan to work on CRUD apps in a financial organization, but if technological aptitude is an enabling factor for a company you're applying to (that's the case for companies in Silicon Valley: otherwise there's no point to being in the most expensive part of the country), you should understand more than your segment of the stack (that goes both ways: systems programmers should still understand HTTP and high level languages if they work in a web services company).
You still get what you need as an interviewer; even if you don't know the parameters, you should still see basic error checking, you can learn a lot if they don't provide the correct parameters, etc. This approach also allows you to implement the "don't know the language" interview; I don't really know PHP but I've interviewed people in it, because I know it well enough to see the things I am looking for. In that case I don't even know the precise parameters to open to "nail you" on them in the first place! But that's not what I'm looking for.
I'm usually not playing the compiler type during the interview. Pseudo code would probably work since I want to see problem solving. (But those who could write pseudo code could just as easily substitute in their language de jour).
The trouble is that unless someone is highly referred from a technical coworker you trust, it's going to be hard to know in advance if you have the technical chops or not.
Anyone can write down on their resume they've done A, B, C and are well-versed in X, Y, Z. They might even be able to talk the talk. But when it comes to writing code they might completely freeze or write something that would make college students blush.
Finally, the time is limited (could be 45 mins, could be 1 hour) during the interview, and the most important thing in most peoples minds is technical chops. That's why I'll usually start out with that (unless the candidate was referred or seems highly qualified, in which case I'll merely get into that later), since it could just weed out the candidate before getting very far.
With your regard of "Convince me why I want to work at your company," I think that only happens once a candidate has proven to be worthy. At least in my last company we would be in "sell" or "buy" mode for a candidate (sell meaning we try to convince him/her to join, buy meaning we try to convince ourselves if he/she should join) and it would start out in buy mode.
There's nothing worse than interviewing and hiring a candidate with a great personality than just finding out he/she couldn't code their way out of a paper bag. That being said, I do dislike interviews where they spend the entire time just asking technical questions as it should be obvious after one or two, so a particular balance needs to be sought.
WRT convincing. Sure you start off in buy, since you're hiring. But you should be open to the thought that a great candidate probably has other great options on the table, and they need to vet those out. Ideally you would provide them that opportunity.
And even if the candidate does have the code up, not all interviewers would bother spending the time to look at it. At the end of the day I think it is based off some kind of reputation on whether or not people believe in the technical chops enough to skip asking the candidate the question.
And it's really hard to draw the line between belief and sloppy interviewing where they simply forget to ask.
I wonder, in your cases where you experienced the ideal interview, which factors do you think contributed to it?
Afterwards I told my boss, "This guy is a total miss. He just writes Perl scripts to munge log files. Why did we even talk to him?"
"Oh, he's a really sophisticated low-level network performance guy. He has a lot of hands-on knowledge of networking hardware and protocols."
Well... shit. I guess munging log files can be more than just munging log files. I couldn't tell that from his resume, though, and he didn't give me any clue while he was talking to me. Was that my fault?
If you didn't decide to interview him, or set it up, you should have asked the person who did (in this case, your boss) what it was about the person that caught their attention in the first place. Why did your boss think this was worth pursuing? With that knowledge in place, it would help shape your questions.
Its so simple but an amazing number of companies just will not take this simple step. So rude, and people remember things like that.
Sometimes it is your personality; some employers are trying to build a team, and it takes a combo of skills AND group fit.
And ultimately, their answer would probably not be very helpful. Are you looking to improve or to find a way to cope/rationalize with the rejection? If you are honestly looking to improve, all they can tell you is how you might improve for them. What is the expected next step? Apply again? Complain about how they should give you a second look? Nah, it is probably go elsewhere and hope a different company shares the same opinions on how to hire people so that your newfound knowledge is useful.
I am not saying I disagree with the sentiment. It is just as helpful as flicking off a stranger on the road. Makes you feel good. Doesn't land you a job. No doubt there are a few anecdotes to the contrary, as there are always exceptions, but the legal and subjective aspects can erupt into some ugly encounters nobody really wants. Just the fear of that is enough.
I understand the need for startups to screen out absolute idiots before they spend time talking with a candidate; it's easy enough, though, to look the guy up beforehand or send the guy a coding question he could work on in isolation. Just make it a policy to only talk to candidates that have something technical you can verify beforehand.
In our current tech job market, it makes sense for the company to convince you it makes sense to talk to them further; chances are, if you're any good and someone they want, you can and will get multiple offers anyway. Even if the company wastes "talk time" to candidates that wouldn't make the cut, it's worth not driving away the guys who got annoyed by its strong-hand "we need a strong code monkey" interviewing tactics.