Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We Hire the Best, Just Like Everyone Else

blog.codinghorror.com

Post reply on HN
Print view View original

41–50 of 373 posts

Re: We Hire the Best, Just Like Everyone Else

#41

Post by pc86 »

OpenDrapery wrote: post #29

I work in the "boring" old insurance industry, based in the midwest. I love reading articles like these, and as I read them I get excited and say to myself "yea!" and "spot on!". But they seem to center around startups and Silicon Valley. The truth is, when it comes to building, maintaining, and supporting internal, line of business apps, management isn't even pretending to look for high end talent. They want predict…

HN obviously has a large bias toward content that is relevant in Silicon Valley (understandably so). This makes it fairly likely that the content that is only relevant to SV still makes its way to the top of the front page from time to time.

It may be counter-intuitive, but I find it easier to apply these types of articles to my non-programming work. My wife and I own a gym, and we need to hire personal trainers from time to time. There's a certifying body for that, so it's easy to know if someone is trivially "qualified" for the job. Are we trying to hire the top 1% of trainers in the country? No, we're at best a medium-sized location for our area. Largely what we look for when hiring is how they will fit in with the existing coaching staff, how they will fit in with our existing clientele, and how likely they are to attract new clientele (or bring with them).

Re: We Hire the Best, Just Like Everyone Else

#42

Post by robterrell »

struppi wrote: post #33

Also: Give the "not-the-best" people a chance to develop. The CEO of one of my past clients, a consulting company, always said: "You can teach everyone to be a great programmer". And he put his money where his mouth was: He hired people with no programming experience (even with no university education) and personally trained them for several months . Also, senior people in the company were encouraged to also help the…

That's awesome. You should credit him by name. I want to keep tabs on that guy.

Re: We Hire the Best, Just Like Everyone Else

#43

Post by webjprgm »

humanrebar wrote: post #25
karterk wrote: post #6

This might be an unpopular opinion on HN, but another example of this problem manifests in the sheer volume of companies that require a HackerRank screening test these days. Apart from the clumsy web editor, recording someone under a time constraint means nothing in the larger context of how a programmer's actual work happens. Sigh. By using such automated tests, companies want to identify top talent by taking a shor…

People who ask for more complicated code than "reverse a string" or "fizzbuzz" in a remote code screen is doing it wrong. People who can't code, compile, and run a fizzbuzz in an hour are probably not fit to be hired. Asking someone to implement a proper Diffie-Hellman over Hackerrank is ludicrous, on the other hand. Interviewers should err on the side of stupidly simple problems. A surprising number of people can't…

The one time I tried a fizzbuzz in a series of interviews, one candidate was surprised and almost insulted. At the end of the day, I learned almost nothing about any of the candidates from this question. Only one candidate (in fact, the one female candidate) implemented it substantially different than any other. All the candidates could do it. They were all CS students at a university, so what was the chance they were not going to be able to compile a program anyway? So I think you have to take fizzbuzz with a grain of salt and know when to try a more complex programming exercise.

(That being said, I'm horrible at doing interviews so take my advice with an even bigger grain of salt.)

Re: We Hire the Best, Just Like Everyone Else

#44

Post by pc86 »

was_boring wrote: post #38
OpenDrapery wrote: post #29

I work in the "boring" old insurance industry, based in the midwest. I love reading articles like these, and as I read them I get excited and say to myself "yea!" and "spot on!". But they seem to center around startups and Silicon Valley. The truth is, when it comes to building, maintaining, and supporting internal, line of business apps, management isn't even pretending to look for high end talent. They want predict…

I had a job like that once, and it was clear to me I didn't fit there for a variety of reasons so I left because I wanted to make a difference at my job and not be a "resource". I then got a job at a "stable" startup working remotely for twice the pay that the boring industry would pay.

No need to create a throw-away account to share your personal experience.

I've worked in traditionally boring industries that treated programmers as resources to be allocated (healthcare, logistics). Sometimes it's still possible to make a difference. For example the logistics job I had, we were often the only development resources our clients had, so when they wanted to run a promotion or do something like that, our execution could literally make or break their business.

Re: We Hire the Best, Just Like Everyone Else

#45

Post by webjprgm »

Tenhundfeld wrote: post #39
humanrebar wrote: post #25

Earlier quoted context omitted.

People who ask for more complicated code than "reverse a string" or "fizzbuzz" in a remote code screen is doing it wrong. People who can't code, compile, and run a fizzbuzz in an hour are probably not fit to be hired. Asking someone to implement a proper Diffie-Hellman over Hackerrank is ludicrous, on the other hand. Interviewers should err on the side of stupidly simple problems. A surprising number of people can't…

>A surprising number of people can't code a loop in the languages on their resumes. I guess you can reach two conclusions from that: 1) A surprising number of applicants are totally misrepresenting their abilities – either through deceit or wild ignorance. 2) Something about your interview process makes a surprising number of people unable to perform at their normal level – from nervousness, unrealistic and artificia…

Misrepresenting abilities ... yes, I did that in my first job interview. The job posting said PHP, HTML, MySQL skills. Well, I knew HTML well enough but my PHP and MySQL skills were from a few side projects doing copy-paste-modify with PHP BB's code base to make my own web app, which I never did finish. So I only kinda/sorta knew those languages.

But then at the end of the interview I was given a coding challenge to do at home over the next few days. PHP and MySQL have good online documentation so I was able to knock it out quickly and I got the job. So, yes I misrepresented my skills, but I also knew I could live up to what I was claiming I could do.

Re: We Hire the Best, Just Like Everyone Else

#46

Post by elcapitan »

OpenDrapery wrote: post #34
elcapitan wrote: post #11

Earlier quoted context omitted.

It works well in my experience, but we have only used it at smaller scale. 2-3 days working together with somebody is already way more telling than stupid interviews, buzzword compliant skillsets and unrealistic tests.

How would it work in "your experience" if you were the job seeker and not the interviewer? Taking a week of PTO to interview and then not get the job is a pretty big sunk cost. I guess you can only do one of these a year.

We paid them the equivalent of well-paid consulting work for the time they worked with us, so I would be fine with that.

Re: We Hire the Best, Just Like Everyone Else

#47

Post by aduitsis »

neverminder wrote: post #16
karterk wrote: post #6

This might be an unpopular opinion on HN, but another example of this problem manifests in the sheer volume of companies that require a HackerRank screening test these days. Apart from the clumsy web editor, recording someone under a time constraint means nothing in the larger context of how a programmer's actual work happens. Sigh. By using such automated tests, companies want to identify top talent by taking a shor…

Couldn't agree more with this. Also Codility tests in which fresh graduates do very well and more senior engineers fail, because most of the academical/theoretical/generic stuff is forgotten since it's rarely needed in the real world.

I've seen people that have solid proven development experience of more than a decade, investing time preparing for coding interviews(!). And, in a perverse way, it makes sense because they know that they are going to be asked to do something their experience has little to do with and most likely forgotten after university.

Re: We Hire the Best, Just Like Everyone Else

#48

Post by falcolas »

OpenDrapery wrote: post #34
elcapitan wrote: post #11

Earlier quoted context omitted.

It works well in my experience, but we have only used it at smaller scale. 2-3 days working together with somebody is already way more telling than stupid interviews, buzzword compliant skillsets and unrealistic tests.

How would it work in "your experience" if you were the job seeker and not the interviewer? Taking a week of PTO to interview and then not get the job is a pretty big sunk cost. I guess you can only do one of these a year.

If you make weekends and evenings available, it lessens the cost of the job seeker. If you allow for remote work using one of the many online collaboration tools, it lessens the cost for both the job seeker and the employer.

Re: We Hire the Best, Just Like Everyone Else

#49

Post by webjprgm »

neverminder wrote: post #16
karterk wrote: post #6

This might be an unpopular opinion on HN, but another example of this problem manifests in the sheer volume of companies that require a HackerRank screening test these days. Apart from the clumsy web editor, recording someone under a time constraint means nothing in the larger context of how a programmer's actual work happens. Sigh. By using such automated tests, companies want to identify top talent by taking a shor…

Couldn't agree more with this. Also Codility tests in which fresh graduates do very well and more senior engineers fail, because most of the academical/theoretical/generic stuff is forgotten since it's rarely needed in the real world.

So a more realistic test would let the candidate use Wikipedia to refresh his/her memory, but then you would need more complex questions that require demonstrating understanding, like being given a chunk of real code and applying the theoretical concept to improve it.
Post reply on HN