Skip to content

Comment on Today's Coding Interview Game

Comments

Coding general solutions should be par for the course. I agree that some interviewers are coming up with contrived examples. But of the 6 data points I have now from hiring people, those who could code on the white board turned out to be good employees (4 of them) and those who could not turned out to be a vast waste of time (2 of them). As jconphoenix was alluding to, I would have rather ended up rejecting more of the qualified applicants than ending up with a time-wasting employee.

I don't really understand this mentality. Is is really that hard to get rid of the charlatans that slip through after the fact? Just monitor them fairly closely (but secretly) for a couple of weeks. Have some sort of object measure of performance for that time period. If they don't pass muster, get rid of them. This seems like a better method than spending 6 months to fill a couple of positions.

Training and getting someone up to speed for a few weeks, then getting rid of them (if it doesn't work out) wastes more time and money than spending several months to fill the position with the right person. Laying people off for performance is hard to quantify, not to mention I certainly wouldn't want to be working for a company who is secretly monitoring new hires' performance.

Some organizations openly set out the first few weeks or the first month or two as a probationary period for new hires, but you're right about the cost effectiveness to some extent. A six month recruiting process might cost a few hours or days every so often from a few employees, but won't add up to even a single month's pay for a bad employee. Add in a cultural practice of risk-averse hiring (don't hire any B or C players) tilts the scales even further.

That said, I can imagine some cases where opportunity cost and being more concerned about getting good employees than immediately weeding out potentially bad employees would lend one to the probationary thing.

Amen. Someone in my orgzn was let go very recently. I'm not in mgmt so only had a peripheral view of what transpired, but the orgzn I'm in is very loose and generally hires strong candidates with very high success rate. We don't have a lot of time to spend monitoring performance closely; we expect people to work independently and deliver in a non-sweatshop environment. Once a problematic situation is recognized, it sucks up a lot of time, energy, and karma (heavy HR involvement, PIP programs set up, tracked, etc.), and of course we have tasks which the individual was expected to be completing; now not so much. Also, the months spent bringing up to speed someone who will now never contribute to the team, time and teammate energy which could have been expended on a better candidate. The net cost has been huge. I remember there were some doubts about this individual at interview time (and our interview process is nowhere near as severe as what is described to take place at Google, etc.), and these were ignored (there were "extenuating circumstanced"). I'm reminded of a quote from Ronin "Whenever there is any doubt, there is no doubt." Even though from a fictional source, it's good advice. Also: "no exceptions".

This sounds like risk aversion to me. People place twice as much emphasis on avoiding loss than they place on gaining something equivalent (even though the end result is the same). If you look at it in this light, then of course the good ones weren't as good as the bad ones were bad. The end result is that you end up with employees who definitely don't suck, but aren't really great either because you spent all of your time avoiding bad programmers and not enough finding good ones.

Given how hard it can be to fire people, I don't blame managers for being risk averse.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.