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.
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.
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.
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.
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?
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).
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.
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.
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?
