Hacker News new | ask | show | jobs
by throwawaysbdif 3493 days ago
I'm not too surprised either, but I marvel at the amount of time wasted preparing and asking all the stupid questions when they could just look at my code for 5 minutes. Like, the main file in one of my libraries clearly uses concurrent locking, it even says so in readme.md . These were all last round on site interviews and we spent maybe 30 minutes of 2 devs time going over pointless stuff when they could just skim 200 lines of code.

I think it's just that they have a process built up over time like "interview process.doc" and the devs don't want to make any waves going off script

2 comments

Github makes it hard to tell what code is yours and what is something you just forked from somebody else.
I thought it showed on the page if a project was forked; perhaps it makes fraud possible but wouldn't it be spotted almost immediately when you started work, if it wasn't spotted then arguably it doesn't matter.
"Almost immediately when you started work" is precisely too late, though. If you hire purely off GitHub and get someone who lifted their code (instead of forking it), that's a huge price.

Bad hires inflict huge costs up front, in wasted interview opportunities and startup costs and lost training time and morale hits and a dozen other things. "Fire fast" is popular advice because it's better than firing slow, not because unsuccessful hires are a sustainable event.

Forks of GitHub repositories are marked as such, forks of projects hosted on other sites are not.
This.

A company, that advertised here on the last "Who's Hiring" sent me a code project.

Wasn't quite enough to be 'you're doing a sprint item for us', but merited decent effort:

- write a log monitoring console program that consumes an actively written to file

- parse out specific parts of the log and aggregate them every 15s, display summary data

- generate 'alert' notification when log messages/second (over the last two minutes rolling average) exceeds a threshold

- remove notification when fall back under this limit

- continue to generate stats while doing so

- develop some unit tests to demonstrate alert logic

This is, at least to me, _several_ hours of decent work. Certainly was nearly 500 lines of code.

Submitted.

"Thanks for this. We'll review."

Last I ever heard.

Thanks.

Last I ever heard.

By all means, please do "out" this company. Preferably as a response their next "Who's Hiring?" posting.

You'll be doing not only your fellow developers a huge favor, but the guilty party as well. Being as they need to get their heads around the fact that it's not in their interest to keep pulling off bad behavior like this -- and if they need a good dose of public shaming for the message to sink in, then so be it.