Hacker News Reader

Comment by lmilcin | Hacker News Reader

I understand your frustration, but I somehow need to figure out who to hire and who not to even if it can't be done reliably.

I need to ask some technical questions and I need to give simple coding exercise on a coderpad.

You would be surprised how many people can smooth talk themselves through any non technical person but can't do shit when faced with an actual IDE and a small problem to solve.

The real broken part of this is that there is minority of candidates who just can't develop and go to a huge number of interviews looking for one place where the process slips up and lets him pass or maybe be very lucky with the questions. Even though they are minority the constitute majority of interviews just because of how many interviews they try to attend.

View on HN

I did mention that a one hour tech talk. I don't think you should willie nilly hire anyone just because they are a smooth talker.

Quick example, Hiring a mobile developer: You talk with them, if Android, ask how Kotlin interfaces with the JVM and what they think (good or bad) about type erasure. iOS? Ask/talk a bit about memory management/ARC. Anyone that has experience with these languages/os (unless hiring for very junior position) should have some thoughts and opinions about it. They may say something you don't agree with (ARC is crap because X or Y) but they will know what they are talking about. You can also dig in to know if it is something they read online (ARC is automated reference counting, meaning each 'allocation' increases a ref counter. Ok, that is good, so, why use `autorelease` or `release` and when to use each? etc etc kind of questions)

You can do the same with backend (framework vs libraries) or frontend (react + state libraries) or whatnot, but if in an one hour tech chat with someone, you can't understand if they actually know they can at least code similar to giving them a fizzbuzz or whatnot, it says more about the interviewer than the person being interviewed.

One technique I use is I ask them what are the things they know well. Hopefully, there will also be something that I know. I then start digging in the area they have already advertised they know well and try to judge what it means when they say they know something well.

Also if a candidate can master even one thing very well, it gives hopes they are at least somewhat interested in development and can learn other things, too.

What I found is that people who are not interested in development but rather do this because it pays well almost never learn anything very well. They just don't have drive and curiosity needed to dig one topic long enough after what they have learned was enough to complete the task they were assigned.

I don't know man, I don't think the coderpad thing should be your litmus test. Would looking at their github and talking over something they've written suffice? Why not? I get too nervous to code in front of someone on coderpad. It sucks, my mind goes blank. But otherwise I'm a pretty goddamn productive programmer. I've interviewed with a lot of places and the only place I could get traction with agreed to forgo the coderpad and just look my github projects over. Everyone else loved me from talking to me but were dumbfounded when the coderpad shit came up. I feel like I'm kind of fucked in this field I've worked incredibly hard for the past decade in.

> Would looking at their github and talking over something they've written suffice? Why not?

For a simple reason. I don't want to select only people that have github projects. I think it is wrong.

If interviewers grade candidates based on github projects then I can bet there will be market for people to fake their projects. It is just reality.

What about creating incentive for people to work entire days, at work as well as on a private project? Is that ok?

You landed your job based on github project? Good for you.

Reply on news.ycombinator.com