Hacker News new | past | comments | ask | show | jobs | submit login

Seems you've had some bad runs.

I can pretty much debunk 1 and 3 personally. Good companies and people take hiring very seriously.




That people sometimes do first, then afterward invent a rationalization for what they did, and then accept that as the reason they did it, cannot be easily debunked.

E.g. woman buys new shoes on pure impulse. At home she finds they go really well with a certain purple dress. Why that's precisely why she got them, of course. Eight months later, that's all she remembers: I had that dress in mind when I saw those shoes.


Our brains not only arbitrarily post-rationalises a bunch of stuff, but we often believe it to be the truth from the moment we think of it in many cases even when the rationalisation can't possibly be true.

(There's at least one study on people with severed brain stems that is fascinating in this respect, but I can't remember where I read about it, and don't have time to track it down)


What would be a polite way to say "I didn't hire you because you have no idea how to program?" I mean I've interviewed people who we didn't hire for that reason... You can't say that though because its mean... Instead you get "your skills didn't align with our needs."


As a CS student who's still not very confident in his skills and without enough experience to recognize his own weak spots, I would say that "you understand X's language well, but you need to improve your knowledge of algorithms and data structures" or "you have a good theoretical understanding X and Y Computer Science concepts but you need to work on side projects to gain programming experience" or "you have shallow understanding of a lot of languages/technologies but I advice you to concentrate on X or Y until you become good at them instead of jumping between L/T".

I know that very few employers would take the risk to be so frank but I personally wish they were. It would be helpful to the candidates who actually care about improving their knowledge and skills while potentially offending those who are trying to fake it.


I'm not talking about that...I'm talking about people who are confused about things learned in CS101. I am assuming you can program FizzBuzz.


"For this job, writing a simple function like this with one for loop should be something you can do without thinking about it."

I've told candidates variants on that theme before.


Very good! I guess I just let my negativity get the best of me in frustration and doesn't make me think in a positive manner.


> What would be a polite way to say "I didn't hire you because you have no idea how to program?"

"This position requires knowledge of programming, particularly in (C, Python, insert details here)."

Dancing around that point is not a "politeness".


But this potentially opens an endless debate against a candidate who is absolutely convinced that they know how to program, and that you're wrong.


A debate can only happen if you continue to entertain their followups with responses. If someone is silly enough to claim they know how to program (or some other critical skill) when their interview demonstrated that they could not, you can simply stop answering their email. It's sufficient to have given them one explanation for why they're not getting the job; that's more than most potential employers offer.


Point being: It's not going to be constructive. Telling someone who thinks they know how to program they can't isn't going to help them and will only seem mean. Because those types can't see they have no idea what they are doing.


On the other hand, it's rare to get someone as far as an interview and have to tell them "you don't know how to program". More common answers would be something specific, like "we need someone with more experience doing collaborative Open Source development", or "we need someone with more skill navigating a complex and unfamiliar codebase and making changes without having to have the entire system architecture in their head". Those are useful and constructive bits of feedback.


Well I said in an earlier comment that our HR team tells us who to interview.


> "if you continue entertain their followups with responses"

That was, incidentally, sekasi's point #3, several parent references up:

"3. Always respond to requests for more information"

No. :)


Perhaps that could be easily revised to:

"3. Within reason, always respond to requests for more information."

Many communication "rules" require the ability to moderate one's interpretation of the rule. I don't think this is any different. It's a good thing to give candidates feedback and if they're confused, the feedback did no good so you should be willing to help them understand. But if they're just unwilling to see the world or themselves for what they are, it's out of your hands and you should leave it well enough alone.


If you "interview" people that are blatantly incompetent, that's on you not on them. Just sayin.


That is hard to avoid, because people are called in to interviews based on how they look on paper. Some blatantly incompetent people write themselves up to look good on paper. They have relevant education, skills, plausible-looking experience and so on.

Following up on some references before calling people in for an interview isn't a bad idea.

Man, I have seen some blatantly incompetent ones. You'd give them a white board and ask them to show a linked list with boxes and arrows. They just couldn't do it.

One case I remember couldn't demonstrate pseudo code for a circular buffer operation based on an array with a head and tail index.


While linked lists are fundamental, depending on the language(s) people have used and how people were taught they may actually not be something people have used. Anyone using mostly high-level interpreted languages (e.g. Python) or something like PHP may not have ever used them, and if they're somewhat self-taught then they may not have encountered them in their reading.

Hash tables might be a better filter, because IMHO you're a lot more likely to find those in real use these days than linked lists.


Your comment is on the mark. But in that particular question they were asked something like, show a singly linked insertion on a white board using some box-and-arrow notation. They were not asked to write it in C or whatever. They couldn't visually whiteboard the concept at all.

(The job area was embedded development, involving C and C++, so asking for C code related to linked lists would have been fair game!)


That is hard to avoid, because people are called in to interviews based on how they look on paper.

And (hopefully) how well they did in the phone screen...?


If you phone screen people and don't call them in for an interview, you are still rejecting them.


But not solely based on how they look on paper.


Our HR tells us who to interview. We'd like that to change, and asked for change, begged even, but thats the way it is. Not everyone works in startups.

(These werr people who couldn't program FizzBuzz)

Plus anyone can just make shit up on their resume.


the questions you asked or the way you asked them were answered in a way that made it appear to you that that person couldn't program. not saying that was the case, but just want to add that line of thinking too.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: