Hacker News Reader

Comment by DavidMcLaughlin | Hacker News Reader

> This works incredibly well. At my last company I fired about a third of the engineers I hired after 3 to 6 months

Wow. I wonder, have you and this smug author ever considered that you are the problem?

Interviewing is a two-way process, it's the candidate's job to back up everything that's on their resume and make sure they present an honest view of their ability but it's also your job to decide if someone is a good fit for your team before making them quit their comfortable job and move to your start-up. By firing a THIRD of all people you convince to join your company, you are both incompetent and irresponsible. Precisely the kind of harmful deadwood people enjoy see getting fired.

View on HN

If you are convinced that someone is the perfect fit for you based on a few interviews, then you've either discovered a bullshit artist or haven't dug deep enough. Interviewing is a terrible way to make a hiring decision. We just haven't discovered a better way to do it.

Interviewing can definitely give you an idea about a person, bull shit artists exist (in vast numbers), but they're not that hard to ferret out at the interview stage, presuming the interviewer knows his stuff and is not some HR flunky.

The trick is that during an interview you can choose to concentrate on the person or you can concentrate on their technical skills. If you manage to concentrate on the person instead then you'll find out soon enough whether they'll be 'good' for your company. The technical stuff is the easy part.

I've never had to resort to 'trick questions' or 'test assignemnts' to find out whether or not someone is capable.

Discussing their past has been much more fruitful in spotting trouble early on.

Interviewing is an art, not a science. There has been a whole lot of fuss about google and other companies getting on the 'metrics' bandwagon. I think that only works because they can datamine tens of thousands of applications and spot interesting trends.

If you're in charge of a start-up or a mid-sized company with maybe 10 to 50 employees the number of people you will be hiring will be much lower and the hiring process itself will consume a disproportionate amount of time.

Keeping your turnover low (as in: hire the right people right away) has an immediate pay-off both in time spent as well as in keeping the peace within your organization, and not investing months of time in to the wrong people only to fire them.

You hit the nail in the head, in my career I have fired 3 people (managed thousands). In the interview game to many people focus on the how long have you used X technology instead of the person themselves.

It is real easy people, interview the person and look for passion, seriously it overcomes all else. As long as the person has no obvious glaring personality flaws and passion, the rest will fall into place.

People in tech careers are for the most part self driven and want to do what they do.

If you (anyone in general) have had a problem with more than 5% of the people who have worked for you, then you may be the problem. Trust me I have meet far more incompetent tech managers than I ever have tech employees.

Who by the way are generally skeptical people who don't follow leaders that they do not respect. Given the grandparents cavalier attitude about firing tech people and the authors I would suspect that they are failing to position themselves as a leader in their technical talents eyes, and loosing their trust with every termination.

Seriously firing people does psychological damage to those that remain, it shows a lack of investment in people that resounds in their mind, it should be reserved for those that refuse to work for whatever reason.

How do you figure out if purported programmers can "program their way out of a paper bag"?

As long as you have a good (enough) method for doing that I agree with everything you say above.

My way of addressing that part was to simply ask what the most complicated thing was they ever programmed, and then to ask one or two follow up questions about that. I've got enough field experience that just by asking that one question I'd be able to come up with a follow up question that would nail a 'poser' in one go, if the answer was satisfactory I'd let it go at that and assume they're telling the truth, if not then I would ask one or two more follow up questions and by then I'd usually know for sure if someone is fibbing or just nervous (people can be very nervous during interviews, the bigger problem to me always was to not discard 'good' people that are simply nervous and botch answers to questions rather than the fear of hiring the wrong person because they manage to bamboozle me).

Another thing I did was to take as much time as I wanted during an interview, I would schedule at most one interview per half day just to make sure that I didn't have to cut an interview short. This made the interview process more relaxed and on the whole gave me enough time to figure out what made someone tick. Most interviews were over very quickly anyway, but every now and then it took a long time to get a feeling for whether or not someone would fit.

One of my biggest discoveries was that when hiring someone good that they would refer their friends, and they would be pretty critical about who they'd refer, screening out a lot of potential duds for me without any effort on my part.

In the Toronto office we ended up hiring four guys that already knew each other previous to joining the company.

This can also work against you, another 'group of friends' applied and I would have been happy to hire just one of them, he stuck with his friends instead.

I once hired a guy that just wanted to learn how to program but did not yet have the ability. This was a risky move, because as a startup you don't really have the time to invest a lot of it in to a person that is not yet proven. But it worked out very well, and Jeffrey actually was one of our most reliably productive people, in part because we gave him a chance that probably nobody else would have.

Sometimes having a will and a drive trumps technical ability.

Interesting.

I've never had the luxury of hiring a non-programmer to learn on the job, but I can see how it could work out. But perhaps you mean "technical ability when hired". I certainly am willing to let someone learn a lot of stuff on the job, including a new language.

However I quibble with your last point, or at least say that some jobs require an ability to grok abstraction, recursion and/or pointers and that no amount of will can overcome an inability to do that.

I'll also note that some paradigms cannot be quickly learned by most. I observed that in general for OO when it became "the thing" in the '90s and I suspect functional programming also takes "more than a month". E.g. one thing I'm saying here is that you couldn't necessarily expect a procedural programmer who already knew C to be able to really learn C++ or Java in a month. Yeah, they could learn how to write C in those languages, but learning the OO paradigm took longer.

Then again, the OO paradigms I learned (which did not include any Smalltalk ones) were both very hard (to get right) and I now think they are also very wrong. Learning functional programming might be much easier for those with flexible minds.

Hence the 'sometimes', that one person was an exception both in that I hired him without the ability to program yet and in the fact that he actually came through in the end, I doubt that that is something you should try to repeat. I just got lucky.

The way I found him was that his father was the cleaner at our offices and if I would please give his son one chance. I did and I never regretted it for one second.

Then again, the OO paradigms I learned (which did not include any Smalltalk ones) were both very hard (to get right) and I now think they are also very wrong.

Based on this and your other comments, I'd like to hear more about how you came to this conclusion. This isn't the right thread for it, though... perhaps, if you're interested in writing about it, you could make a new post?

I can put it simply: the only thing worse than an imperative style with side effects is one where the side effects are chained, in this case through a set of interacting objects. I came to it from the hard experience of doing it, e.g. think sequence diagrams; the methodology was OOSE.

However lately I have been wondering about the utility of this approach for GUIs.

That's been my experience too. "Object model" almost always translates to "spaghetti". The promise of OO -- that objects would provide a flexible abstraction mechanism for writing software at the level of the domain while encapsulating low-level details -- has not been realized in practice.

I think the promise can be realized in pure UI and AI other than that it is much a-due about nothing. COCOA is a good example of pure UI, as well as some of the JavaScript UI kits. I.E Dojo or YUI. Given that UI objects are well encapsulated via OO is is a natural fit. When you get back to the service layer, you end up either writing overly complex OO stuff or butchering the language to make it functional.

Thankfully Rich Internet Applications are cleanly separating these concerns and you can use an OO toolkit for pure UI and a functional language the stand up RESTful services.

The days of bastardized JSP/HTML/TILES/STRUTS/Kitchen sink are numbered, for just that reason. Trying to shoehorn all of these technologies into a server side OO framework was becoming way to cumbersome.

You left out that the promise of reuse doesn't seem to be borne out and is perhaps harder when doing OO than in other domains. Probably because side effects are more pervasive and it's damned hard to design good object hierarchies (and heaven help those who don't have the discipline to keep their class relationships in a directed acyclic graph).

Modularity is a win and OO only superficially encourages it.

I haven't interviewed as a programmer in a long time, so I'm curious, what defines "the most complicated thing was they ever programmed?"

Algorithmic complexity, like a graph database or a computer vision system or an AI? Does it matter if they just read a bunch of papers and implemented the formulas? Does it matter if they used libraries like OpenCV? Does it matter if they decided the best implementation path was to outsource it and use a SaaS like DirectedEdge?

Social complexity, like a Facebook or Meetup or Digg? Does it matter as to whether they came up with the technical architecture or social architecture to actually process all those votes and friend requests and event managements, versus just doing what the tech arch or design lead told them to do?

I've implemented device drivers in x86 assembly (a well-trod path and it wasn't very original work) and AI (for a video game, original work but with lots of abstractions provided) and an embedded systems JPEG block rewriter in C (abused the spec to create something very original, but was ultimately only a few dozen lines of code when all was said and done). Which of these is "most complicated" and why?

Sorry for the sluggish response, I completely missed your comment.

Any one of the answers you gave there would have sufficed to be used as the 'platform' for further discussion, if you had named those three with the 'Which of these is the most complicated and why?' I think if would have led to a very interesting discussion about your past work for a bit.

Let's take the video game AI as an example. My follow up question would have been something along the lines of 'That's an interesting one, what kind of behavior did your AI govern, and how did you go about implementing that?' or 'How did you protect your AI from getting stuck in a loop or becoming too predictable?', or any one of a bunch of questions about the sort of thing you run in to when you build a video game AI. I'd know pretty quickly if you actually did write a video game AI (I wrote a bunch of video games, and even though I wouldn't class the routines governing the bots as 'AI' I think I can relate enough to the problem domain to come up with some questions) or if you're making it up.

For myself, if someone would ask me that question I'd answer a fully integrated cad-cam system for lathes and mills. That one kept me busy for two years, ended up as about 50K lines of high level code and another 20K of assembler to make it fast. The hardest part there for me was the equidistant operation, it took me quite a while to get it right because I'm weak in the mathematical department, it's actually one of the few times in my programming career that I got so stuck on a problem that I hired a tutor to brush up on the required math.

In my opinion that is the easy part, It is a testable skill (not trick questions). I always have a dummy environment set up with a skeleton app set up and once I am down to the last few quys I ask them to write something from scratch. Generally something simple like a CRUD screen that takes no more than an hour. I generally pair with them and work as a sound board to work out the problem with them. It is very natural and puts a real developer in an environment they are comfortable with. As soon as they see an IDE and no trick questions, the good ones tend to fall into a groove. The cool part is that I have learned so many tricks from many of these sessions.

>Wow. I wonder, have you and this smug author ever considered that you are the problem?

I'm positive I am part of the problem but I haven't found a better way for me to build a top notch team given my skill set and inclinations. As we grew I hired a good engineering manager who was able to reduce that ratio significantly.

To reiterate, in the interview process I explicitly lay out the methodology and all the risks involved as I understand the pain, stress and cost that a failed hiring causes. The end result of all of this was a very talented and efficient team that produced a great product which dominates it's vertical.

I'm not sure it's possible to make the right choice every time when hiring - and even if he's firing a third of his hires it means that he's getting it right two thirds of the time.

Given how lousy interviewing is as a method for discerning quality employees, I'm not sure that's a bad result.

This ain't Baseball, it's a horrible result. I would NEVER hire a manager or leader that fired a full 1/3 of his hire. It just shows a lack of any kind of management skill and behavior like this will quickly tell your remaining 2/3rds that you are not very good at management. They will leave soon thereafter. Now, I realize that a lot of the folks on YN are young and probably thrust into their first management role without any training or mentorship. Best advice I can give is to NOT discount the generations of study on this topic and try to make shit up on your own. Read a few books on how to motivate and make employees more productive and you'll be a lot more successful than the idiot blog author

While I agree with the essay (will write on that next), firing a full 1/3 of those you've hired is going to be very debilitating for the organization. And not something I think most startups will be able to afford.

And if you report or have to answer to anyone, they're not likely to be impressed that you hired that many duds/people who just didn't work out.

> firing a fill 1/3 of those you've hired is going to be very debilitating for the organization.

Exactly, hiring the right people is good for the employees (they have steady jobs in an environment where not all the faces are new all the time) and for the company because of the high cost associated with new hires.

The cost of bringing a new employee up to speed is usually taken as anwywhere from 6 to 12 months of their gross pay, assuming they're engineering positions (and that's what we're talking about).

For other work the cost can be lower or higher depending on how much time and effort needs to be invested by the company to get a new hire up to speed on the company procedures, code base (in case of software), work out team issues and any in-house training programs.

And if you report or have to answer to anyone, they're not likely to be impressed that you hired that many duds/people who just didn't work out.

I think it's important to note that the author is writing from the viewpoint of a serial entrepreneur, which means the context is small startup environments.

Presumably he still might answer to a board, but those may all be co-founders. Regardless, I don't think they would need to be impressed by his management style so much as his end results.

How many startups are funded entirely by real co-founders? Some, I'm sure, and a lot more now, but is that the exception rather than the rule?

So if you have "normal" investors, unless the board that includes them is really hands off they'll notice and I can't imagine it will help his credibility. If it's that hands off you're in trouble in that they aren't likely to be very committed to the venture.

I'm not suggesting funding entirely by co-founders but, rather, controlled by them.

It also seems a bit like speculation, unless you're a VC or angel who has seen this.

Exactly! This concept of "firing" is the purview of assclowns. People that have no management skill yet who lust after director or VP titles after a year in the industry. These people are doomed to building small things. Small companies, small product, small careers. You better wake up and realize the world is made up of people not code.

Reply on news.ycombinator.com