4 ms·

I straight up refuse coding challenges. I code in the open on GitHub quite often and have built plenty of very high quality (and complex) web applications which

I straight up refuse coding challenges. I code in the open on GitHub quite often and have built plenty of very high quality (and complex) web applications which I can go into intricate detail about. If your company can’t figure out I’m a good hire without having me jump through your hoops then your process is trash and I have no interest in working for you. In fact, I’ve been thinking how I would approach interviewing candidates. It seems to me a much better way to interview would be to have candidates do a bit of a show and tell with a project they found challenging. Come in, bring your computer, show me what you’ve built. I’ll do my best to understand it, then I’ll ask questions about it: which aspect was the most technically challenging and why, what was your favourite part to work on, least favourite and why, what would be your scaling strategy and have them go into detail about that, etc. I’d much rather hear how a person answers questions about a project they’re very familiar with than have them do a bunch of arbitrary code problems. What’s wrong with this approach?

Redoubts 7y ago
That’s great. But for some reason every github profile I get to review is just an empty shell or a bunch of one commit Mooc templates. I’ve almost stopped looking at them.
- TomVDB 7y ago
  You could take that a great filter: if people explicitly lead you to their empty GitHub account, what does it say about their judgement?
- unicornfinder 7y ago
  Truth be told I'm far too busy writing software for my current employer to maintain anything decent on Github. I can't imagine I'm the only one.
kasey_junk 7y ago
There are _tons_ of very good engineers who have spent the majority of their careers in extremely restrictive IP environments and cannot talk about the projects they are working/worked on recently without violating contracts. Further, there are _tons_ of very good engineers that cannot do 'a bit of show and tell' easily. They basically shut down. Doing the process you outline will optimize for talkers, and the industry is full of people that can talk but can't do.
- lwansbrough 7y ago
  > There are _tons_ of very good engineers who have spent the majority of their careers in extremely restrictive IP environments Don't take those jobs if you want to be hireable I guess? You'd have to be joking to think a HackerRank quiz is going to help you glean any information about their expertise. Such expertise, by the way, is something I'd like to know about. Figure out a way to talk about it. Tell me the situation (you can't disclose real details) and then tell me about a hypothetical project with similar parameters in a way that doesn't break your contract. Or make up an imaginary project -- if you're actually a good programmer you can come up with something that sheds light on your technical ability and understanding. > Further, there are _tons_ of very good engineers that cannot do 'a bit of show and tell' easily. I'm sorry, soft skills are essential at my imaginary company. You need to be able to explain your thinking at an abstract level. I don't care if you can't do whiteboard problems, I get that - I can't either - but you do have to be able to walk through problems with other people. Especially problems that you know and understand well. If it's the interview environment that's the problem, well I'd like to informalize that process as well too so people don't feel so nervous about the whole thing. But if you can't explain a problem to somebody 1 on 1 then you'll probably be a very annoying person to work with. > Doing the process you outline will optimize for talkers It would optimize for "explainers", not "talkers". Talkers are usually people who can't explain something, and they're fairly easy to weed out from the people who actually know their stuff.
  - kasey_junk 7y ago
    You misunderstand. There is a very common class of engineers that have no problem describing and explaining their work to their peers. They do have a problem with doing it in an adversarial and stressful situation like an interview. I've seen it happen to engineers I _know_ are good. Also, over years of actually engineering hiring pipelines for software engineers, I've seen no evidence that its easy to weed out the good talkers. Quite the opposite I think it's one of he hardest things about designing these pipelines. > Don't take those jobs if you want to be hireable I guess? My point about this is not on behalf of the person being hired, its the person doing the hiring. Your process creates false negatives. False negatives in hiring pipelines is nearly as expensive as false positives.
suzzer99 7y ago
The best interview I had, we worked through a real world project - a like button widget to allow 3rd party sites to embed. We talked about the DB choice, the front end structure, etc. It was great. Unfortunately that was the company that was all 25-year-olds and had a terrible commute, and when they heard my previous salary all interest dried up. But all interviews should be like that imo.

Redoubts 7y ago

That’s great. But for some reason every github profile I get to review is just an empty shell or a bunch of one commit Mooc templates. I’ve almost stopped looking at them.

TomVDB 7y ago
You could take that a great filter: if people explicitly lead you to their empty GitHub account, what does it say about their judgement?
unicornfinder 7y ago
Truth be told I'm far too busy writing software for my current employer to maintain anything decent on Github. I can't imagine I'm the only one.

kasey_junk 7y ago

There are _tons_ of very good engineers who have spent the majority of their careers in extremely restrictive IP environments and cannot talk about the projects they are working/worked on recently without violating contracts. Further, there are _tons_ of very good engineers that cannot do 'a bit of show and tell' easily. They basically shut down. Doing the process you outline will optimize for talkers, and the industry is full of people that can talk but can't do.

lwansbrough 7y ago
> There are _tons_ of very good engineers who have spent the majority of their careers in extremely restrictive IP environments Don't take those jobs if you want to be hireable I guess? You'd have to be joking to think a HackerRank quiz is going to help you glean any information about their expertise. Such expertise, by the way, is something I'd like to know about. Figure out a way to talk about it. Tell me the situation (you can't disclose real details) and then tell me about a hypothetical project with similar parameters in a way that doesn't break your contract. Or make up an imaginary project -- if you're actually a good programmer you can come up with something that sheds light on your technical ability and understanding. > Further, there are _tons_ of very good engineers that cannot do 'a bit of show and tell' easily. I'm sorry, soft skills are essential at my imaginary company. You need to be able to explain your thinking at an abstract level. I don't care if you can't do whiteboard problems, I get that - I can't either - but you do have to be able to walk through problems with other people. Especially problems that you know and understand well. If it's the interview environment that's the problem, well I'd like to informalize that process as well too so people don't feel so nervous about the whole thing. But if you can't explain a problem to somebody 1 on 1 then you'll probably be a very annoying person to work with. > Doing the process you outline will optimize for talkers It would optimize for "explainers", not "talkers". Talkers are usually people who can't explain something, and they're fairly easy to weed out from the people who actually know their stuff.
- kasey_junk 7y ago
  You misunderstand. There is a very common class of engineers that have no problem describing and explaining their work to their peers. They do have a problem with doing it in an adversarial and stressful situation like an interview. I've seen it happen to engineers I _know_ are good. Also, over years of actually engineering hiring pipelines for software engineers, I've seen no evidence that its easy to weed out the good talkers. Quite the opposite I think it's one of he hardest things about designing these pipelines. > Don't take those jobs if you want to be hireable I guess? My point about this is not on behalf of the person being hired, its the person doing the hiring. Your process creates false negatives. False negatives in hiring pipelines is nearly as expensive as false positives.

suzzer99 7y ago

The best interview I had, we worked through a real world project - a like button widget to allow 3rd party sites to embed. We talked about the DB choice, the front end structure, etc. It was great. Unfortunately that was the company that was all 25-year-olds and had a terrible commute, and when they heard my previous salary all interest dried up. But all interviews should be like that imo.