Hacker News new | ask | show | jobs
by pc86 3361 days ago
I help out with interviews at my employer and unfortunately we get a lot of applicants who just can't code. I'm tired of hedging around the topic, so I'll come out and say it bluntly. We get people who say they are developers and are outright lying. We're not looking for computer scientists, or engineers, or anything of the sort. We're looking for people who can program and won't lie about their skills right to our face.

When you have your 10th interview with someone applying for a senior front-end job and they can't tell you how many columns are in Bootstrap, when Bootstrap is on their resume and they made a point to bring it up in the interview, it makes you question humanity. Unfortunately this is why you end up with questions like "What is the difference between `unapply` and `apply`?" or "How many columns are there in the Bootstrap grid?"

And unfortunately, especially in my geographic area, the majority of work is done as an employee or a consultant under an NDA. Nobody is bringing a GitHub profile with a solid green commit graph, nobody is coming with 45k rep on SO, and nobody is coming with years of blogging content we can look at. That's not necessarily a problem, especially if you've ever been in the same room as someone who is very proud of how many SO points they have, but it certainly complicates interviewing.

So when you have a combination of (A) people who lie through their teeth to get a job they are in no way qualified for; and (B) people with no public technical profile to speak of, you end up with interviews full of trivia to make sure they have a pulse and contrived whiteboard coding to make sure they can understand the fundamentals. This is doubly hard if you're trying to respect people's time and limit interviews to a brief phone screen + a 60-minute onsite interview. Some of the suggestions I've seen here about take-home projects, consulting work, coming into the office for 2 paid weeks, or a 3-day long interview bonanza, are insulting.

2 comments

You are not kidding! I hire front-end devs and candidates constantly and utterly lie about their HTML/CSS/JavaScript experience (I've had more than one them tell me when we spot it, "Well, it's just HTML and CSS"). We can weed out some via interview questions but for others it's not until we get to our a hands-on coding test (where we watch what they do in real time) that we can spot it. It's extremely frustrating and such a waste of time for us. They are allowed to look things up in our hands-on tests, as we're trying to replicate real-world enviornment, but it still lets us see overall if they can actually implement what we just talked about in our interview (otherwise the questions we asked are useless), and more importantly, if they told the truth about what they just said. The truth has become very important to me in evaluating candidates -- I'd much rather have people say "I don't know" than pretend they know something, and esp. in our fast-paced work environment, we just don't have time for people pretending to know something they don't. How I see it is if you're wiling to lie in an interview then I don't want to work with you. So the two have come together for me, and at least we have this red flag now that I simply will not hire people who lie in any capacity (and a great green flag when people are honest about what they do/don't know).
I'll take the take-home project. Though I communicate fine otherwise, I stutter miserably when an interviewer is staring at me while I'm trying to whiteboard.

Be a little flexible; not everyone finds the same things "insulting".

I've done take-home projects as well, and I don't have a problem with them, but I do understand why someone who may be looking for a 9-5 may not want to spend their evening(s) or weekend doing a packet of stuff for an interview. I don't want to exclude those people from being able to apply and be successful.