The hiring process is a response to the fact that employers cannot trust a single word candidates say about their experience. This isn't paranoia. Literally, most candidates we see cannot code, even when they supposed have a decade or more of industry experience.
If the industry wasn't so full of lying incompetents, it wouldn't be an issue.
Others have definitely mentioned this experience. For me, I have encountered this very rarely. More common, IME, has been people who seem like they have a TON of deep experience in something but then, when pressed or inquired, only have shallow experience. So, in short, I don't run into people who claim to code but can't as often as I do people who can code at least a little bit but quickly are unable to deal with more complex technical problems, or more expansive knowledge of the language they prefer or use most.
I'm in that group you interviewed. Didn't know what perm-gen is although I've seen it in errors when java used up all memory. Next question was about Hibernate's different caching levels.
I've been rejected enough to eventually learn all these. Then finally when I got hired, questions were the very basic define static, inheritance etc.
I knew it was a matter of numbers and should not mind the devastating feeling of rejection. But damn, you can never know how it feels experiencing tons of rejection until you do.
The hiring process is a response to the fact that employers cannot trust a single word candidates say about their experience. This isn't paranoia
Here's the thing tho': my CV is honest and my track record is pretty good: some small companies and some name-brand, well respected in their industries, known for probing interviews, over about 20 years. There may be some bad actors in the global candidate pool. But seriously, asking me these questions is like tearing my CV up in front of me and calling me a liar to my face.
I am not in the market right now and hope not to be for a good while, but I dream of being asked a stupid whiteboard question, solving it, then throwing the board eraser at the interviewer's head and walking out...
I see on this board more than any other where people will agree that taking time to hire correctly is by and far more cost efficient than hiring quickly, but incorrectly. I've definitely gone through a lot of experiences now where someone looks like a rock star on paper, have a great cultural interview, and we don't give them a ton of technical exercises, only to find out that they can't hack it or, even worse, are dragging down the rest of the team. I really wanna trust people on this stuff, my instincts are to appeal to the greater good in people, but I've been burned enough to not trust it anymore.
The problem is that a lying liar will also have a resumé like yours. How can I — who have never met you, and have no-one I trust recommending you to me — differentiate between gaius the awesome developer and gaius-prime the lying liar? I've got to administer some sort of test to distinguish the two, and the likeliest sort seems to me to be one which attempts to discern whether one knows the sort of stuff gaius would know, and gaius-prime wouldn't.
Which makes asking for a resume, rather pointless. There would likely be a lot more acceptance of fizzbuzz take home tests and so on; if that was instead of writing up resumes (replace one time suck with another instead of adding a second one in). However that makes it hard to justify paying recruiters.
Given how Da Vinchi had a resume its amazing we still use them. (His was better thoigh, it had his name and address, dates he worked for people and their names and address)
>Which makes asking for a resume, rather pointless.
I wouldn't go that far. It still weeds out the honest-but-unqualified with minimal effort - it's basically a good early filter. This actually works for the candidate too - how much would it suck to 6 hours of interviews and then get told you don't have the right degree or some such?
I can tell within 10 minutes if someone is genuine or not just by talking through real, representative scenarios. If the job really involved implementing red-black trees from scratch, then and only then bring it up!
It's so funny, people who support that garbage just aren't hearing it. This forum probably has some of the best developers in the world chatting, and these guys just refuse to change their ways, regardless of how many people tell them it's a bad idea.
It's a bit rude but until senior-level-role-interviewing candidates can stop falling over on the basic questions why waste time with harder ones? The "candidate with an MS degree in CS and x years at SomeCo, can't do FizzBuzz" isn't a myth, it really happens to people giving interviews.
I've been having to give some interviews lately (though unfortunately they have to be within 'process') and my basic question is to write some code (with a computer) that outputs the endpoints of a line segment which bisects a plane between two input control points. (I give all the equations needed and the code is done within an application already set up.) It's still managed to trip up some people with experience who seemingly don't have the concept of representing a line mathematically (BS or MS in Physics, how?). We also tested it on intern candidates under shorter time constraints and a couple internal people, they did much better, I think all but one actually got the basic line done within half an hour even if edge cases remained. If we're given longer time constraints the problem and application framework scales to more interesting subjects like generating n-point voronoi diagrams and their applications, but we haven't gotten there with anyone yet...
> "candidate with an MS degree in CS and x years at SomeCo, can't do FizzBuzz" isn't a myth
I've interviewed many candidates. It happens to find people that cannot code at all.
Yet, one does not propose trivial coding challenges like FizzBuzz. Very little is gained from finding out that a senior developer can do FizzBuzz and then fails at any more complex coding. You simply go for more complex questions straight away.
If you can't tell in a ten-minute casual conversation whether or not someone is grossly lying on their resume, you probably shouldn't be an interviewer.
That's not realistic. You and I are complete strangers; we can have a talk for 10 minutes where not a single word that comes out of my mouth is true and you'd be none the wiser.
If you are a programmer, you can tell; just ask them about their previous projects. Dig into their answers and ask follow up questions. What data structure did you use to do this part? What in the database was designed poorly and why? (Every database has a design issue).
I mean if you were at a party and some guy came up to you chatting, claiming to be a senior whatever at BigTechCo, you'd start chatting him up and you could tell if he was full of BS pretty quickly.
I think so, I personally prefer the "look at this already written code, what does it do and can we find any bugs or issues?", less stressful and more collaborative, but good luck getting any non-startup size company to let you do it.
I do something reasonably similar all the time at Google for iOS interviews, few hundred lines of obj-c with some issues in them (actual issues, not typos)
If the industry wasn't so full of lying incompetents, it wouldn't be an issue.