There is no such thing as good hiring, only good firing
fonality.com
fonality.com
Note: someone might say that I was the problem, which may be true, but I wasn't let go either, so my point still stands ;)
I am upfront about the winnowing process during the interview, it scares some candidates away but I often get a very positive reaction to this "meritocracy by proof" approach. Another advantage is you can take some flyers on people with nontraditional backgrounds and find the occasionally diamond in the rough.
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.
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.
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.
As long as you have a good (enough) method for doing that I agree with everything you say above.
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.
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.
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.
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?
However lately I have been wondering about the utility of this approach for GUIs.
Modularity is a win and OO only superficially encourages it.
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.
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?
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.
Given how lousy interviewing is as a method for discerning quality employees, I'm not sure that's a bad result.
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.
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.
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.
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.
It also seems a bit like speculation, unless you're a VC or angel who has seen this.
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.
A full third is really very high. Consider apprenticing yourself to someone more experienced for a while to figure out what it is that you are missing while hiring, especially if the absolute numbers are high. If you've hired six people in all your time and fired 2 of them then we'll take it as a statistical anomaly.
Out of 25 people hired I've had to fire exactly 1, but I rejected almost 95% of all applicants to open positions, not limited to the engineering department.
I think one big difference in the way we look at this is that if you hire someone you also have a responsibility to them, evaluating fit is something that is your responsibility, and failure is up to you to correct, through teaching, training and mentoring.
It seems you think that you have no responsibility for them other than to fire them when you've decided your 'extended interview' is over.
In most countries there is an agreed upon 'trial period', which allows an employer to terminate a contract without any penalties, depending on the country these periods last from 30 days to 6 months. But it is actually pretty rare to have to fire someone within that period, even if there does not have to be 'cause' a high firing rate during the trial period reflects bad on the hiring manager.
The reason for that is simple economy, hiring people and firing them within 6 months is a very bad investment for the company, that person cost almost as much in time spent getting them up to speed as a person that is productive for multiple years.
If you're hiring someone that is out-of-work and down on their luck then you could argue that something is better than nothing and you gave them a chance, if you entice people to leave a job where they've worked for years and you then end up firing because of a mis-judgment them you've caused a real problem.
And it won't do anything good for you company's reputation. Read Death by Lethal Reputation http://www.asktheheadhunter.com/halethalrep.htm; I'll also note that failed startup Thinking Machines (the Connection Machine company) had absolutely the worst hiring practices of any Cambridge, MA area company in the '80s (details upon request).
I've worked mainly in startups and think that startups rarely approach their potential. The managers often comfort themselves with delusions, and the employees for their part often passively take the work they're handed.
Like a men's club, one blackball from any employee and you weren't hired. I think this is documented, and I don't know how long they continued the policy (see below, I passed that test).
Early on at least they took forever to hire. E.g. I did a serious interview with them (my interview with Danny Hillis, who was part of my social circle, started with an aggressive "Why aren't you in school!??" (the answer was money)). They got back to me more than a month after that interview, by which time I'd accepted a much less desirable job (sysadmin for their Lisp Machines).
I was told they failed the second time to fill this job and that three full calendar years later (!!!) they hired a classmate of mine in their third try (I pretty much knew the entire talent pool available at the time).
We can be quite certain that damaged their productivity early on; my experience was at the very beginning of 1984 and I'm not sure they failed to hire anyone for this slot in the meantime.
In one well sourced account, they asked for a reference from an applicant's current employer (of course without clearing this with him first). Except for that case, I've never heard of anyone doing that, ever.
While they were the coolest place to work at in Boston, I can see how they might in part have suffered a "death by lethal reputation" (there are many additional and well documented reasons in the public record, of course).
http://thedailywtf.com/Articles/Thinking-Machines.aspx
I agree, I've never even known a company to even verify anything on a resume, much less tip off an applicant's current employer.
This advice seems ill-suited to someone founding a startup. A founder is a manger out of necessity, not out of an affinity for people-managing. Are such apprenticeship opportunities readily available?
As someone who has only been on the receiving end of managerial treatment, I agree, emotionally, with your position (and presumably would enjoy working for you). However, I'm not sure it makes rational sense.
It seems you think that you have no responsibility for them other than to fire them when you've decided your 'extended interview' is over.
It's important to note that it's an extended paid interview.
The reason for that is simple economy, hiring people and firing them within 6 months is a very bad investment for the company, that person cost almost as much in time spent getting them up to speed as a person that is productive for multiple years.
I've heard and read assertions to this effect before. Do you have studies (or even anecdotal evidence) you could provide that would quantify this?
This also begs the question of the overall productivity of the team, rather than any given individual, or is that what you mean by time spent getting them up to speed?
if you entice people to leave a job where they've worked for years and you then end up firing because of a mis-judgment them you've caused a real problem.
Possibly, but if the firing is from a startup and the stable job was a larger company, I suggest this is to be considered part of the risk.
I did exactly such enticing with a friend and colleague of mine to a startup which eventually failed (and again to another one, which is perhaps in the process of failing).
His original employer valued him enough that they were more than happy to have him back, even a year later. I expect this to extend to all "A players."
For a start-up the rules are a bit different, but in a way for a start-up it is even more important to hire the right people rather than to use a more trial-and-error based approach to hiring.
Start-ups as a rule have less time to lose on stuff like that and replacing a person in a start-up usually carries a severe penalty. The teams are usually much smaller and dropping a team member will have a significant impact, much more so than in a larger organization (but even there it can hurt a lot). A start-up I invested in lost their #2 programmer due to a series of problems and it almost killed the company.
As for apprenticing, the possibility to learn is always present, but maybe not in your own company. When you find yourself in the need of knowledge it doesn't hurt to go through your addressbook, find someone with more experience in the field that you want more knowledge in and ask.
I've done that quite frequently in my career (and I still do that, as some HN'ers can attest to) and I've found that people are usually very happy to teach a new skill or to augment an existing one if you ask them. Of course they're not obliged and you can't make any demands but as a rule it doesn't hurt to ask.
> It's important to note that it's an extended paid interview.
Yes, that's true, there is some compensation. But I always looked at firing someone - and it fortunately was very rare - as a sort of divorce on bad terms. The better way to go about it is to talk things over, if possible help find your employee a spot where they're more in their place rather than at a high pressure start-up where the margin for error is a lot lower.
> I've heard and read assertions to this effect before. Do you have studies (or even anecdotal evidence) you could provide that would quantify this?
As a rule I ask companies where I do technical due dilligence how long it takes them to get a new hire up to speed. The companies where this goes fasted are around the 3 month mark, as a rule those companies have fairly simple systems and no long running projects or large code bases. The longest are around 2 years, these are companies that usually have a limited size in house development team, sometimes requiring skills on the cross roads of two or more disciplines working on technically complicated projects.
On average, assuming a linear increase in productivity over the time that you hire someone to the time that they are as productive as the 'old hands' it seems to work out to at least several monthly salaries of time wasted, for one because the new hire is not yet productive, but also because he/she is a drain on the members that were already productive before the hire was added to the team. The latter factor is one that is overlooked very frequently.
> This also begs the question of the overall productivity of the team, rather than any given individual, or is that what you mean by time spent getting them up to speed?
The team as a whole.
> Possibly, but if the firing is from a startup and the stable job was a larger company, I suggest this is to be considered part of the risk.
That's true, but then only if the person hired is made well aware of the risk and can balance it with a pay-off in proportion to that risk.
When I was young and without responsibilities other than to myself I would work simply on what I thought was interesting and I couldn't have cared less about the compensation, so if I would have gotten fired (which never happened, but theoretically it could have) I wouldn't have cared much about it.
Employing someone with a wife, kids and a mortgage and then throwing them out in the callous way the poster suggests, after hiring them capriciously is really bad for your business' reputation as well as for your employees.
You really don't want to get known as a company bad attitude towards new hires, the better people will simply not even apply to a company like that.
In the end all you'll get is people that more or less expect to be fired in the next 6 months.
One of the best companies that I've read about culture wise was the 'old' HP, I've done my best to try to learn as much as I could from how they treated their employees and I think it did me well. If this stuff interests you, then there is plenty of stuff documented on the web about it, there is also a book called 'the HP way', which contains a few valuable insights.
Other books that I've found great showing me bits and pieces of how to grow in to the role of a manager after being a techie all my life were 'the soul of a new machine' by Tracy Kidder and a book about the very first computers in war time England, but I can't recall the title.
> did exactly such enticing with a friend and colleague of mine to a startup which eventually failed (and again to another one, which is perhaps in the process of failing).
His original employer valued him enough that they were more than happy to have him back, even a year later. I expect this to extend to all "A players."
That's great, but the economy is not what it was several years ago, and I suspect that people leaving a good job will expect their new employers to treat them with some respect, it may be that by making such a move they are taking a considerable risk. Of course, nobody is forcing them, but it doesn't hurt to be careful with other people.
edit: I'm sorry you got modded down, I don't see any reason for that in your writing.
Probably not, unless someone else jumps in, since I actually agree with you and am merely exercising skepticism to solidify my conclusion. [1]
As a rule I ask companies where I do technical due dilligence how long it takes them to get a new hire up to speed
At the risk of quibbling, this strikes me as a couple steps removed from anecdotal. I expect a degree of subjectivity, but without direct observation, it's merely hearsay (not entirely unlike some interviewing techniques, but I digress).
On average, assuming a linear increase in productivity over the time that you hire someone to the time that they are as productive as the 'old hands'
That's a big assumption, and one I would suggest is false for experienced technical people, especially non-programmers.
I detect an additional, implicit assumption, that a new hire's productivity will ever reach (and/or not surpass) that of the veterans around them. Similarly, you're assuming that they will, at some point, cease to be a drain on the team.
Employing someone with a wife, kids and a mortgage
I don't think it's any of an employer's concern what an employee's personal/family situation is, nor appropriate to base hiring/firing decisions on it. Fortunately, the labor laws in my jurisdiction support such a view quite strongly.
and then throwing them out in the callous way the poster suggests, after hiring them capriciously is really bad for your business' reputation as well as for your employees.
This may be true, but you haven't pointed out where capriciousness or callousness (beyond a separation of business and personal) is advocated, either by the OP or the OC.
[1] I hesitate to use the term "Devil's advocate," as it carries a connotation of absence of engagement or conviction.
It's not even removed, it is anecdotal, I don't even know for sure if they are telling the truth, and possibly neither do they. But the universal component seems to be that they all agree that it takes time, so the only thing left to argue about is how much time, and hence roughly how much cost. We're talking about a fair sized sample though, so even if it isn't a research project it will hold some water.
The question is born out of my own experience that it can take some time to get a new hire trained, coupled with a bit of information about the complexity of the subject matter it usually gives me some insight in to how well their documentation is and how good their teams are at communication and dealing with integration issues.
That's a big assumption, and one I would suggest is false for experienced technical people, especially non-programmers.
I detect an additional, implicit assumption, that a new hire's productivity will ever reach (and/or not surpass) that of the veterans around them.
Not necessarily, there is probably some correlation with how fast someone gets up to speed and how far they'll go, sometimes you get lucky and you find someone that managed to outperform the people that you already had. But as time progresses the chances of that are smaller and smaller, simply because of the body of accumulated knowledge by the 'old hands'.
Similarly, you're assuming that they will, at some point, cease to be a drain on the team.
Well, everybody is a 'drain' on everybody else in that respect, but during the initial period where someone is entirely new to something that drain can be considerable.
Especially in those 'rare' cases where the documentation leaves something to be desired. Of course that would never happen in real life ;)
I don't think it's any of an employer's concern what an employee's personal/family situation is, nor appropriate to base hiring/firing decisions on it. Fortunately, the labor laws in my jurisdiction support such a view quite strongly.
No, but that doesn't mean that it hurts a lot more to fire someone for whatever reason if you know that it will affect his or her dependents as well. I agree that's arbitrary but I'm by no means perfect.
Downsizing is the hardest in this respect, it causes no end of grief, nobody did anything really wrong, but still you would have to let people go.
This may be true, but you haven't pointed out where capriciousness or callousness (beyond a separation of business and personal) is advocated, either by the OP or the OC.
I think the capriciousness is in the part where he says 'in startups, where you hire fast and loose', which is something that I don't think is necessary at all, and then corrects the failure to invest enough time in the hiring process by firing an overly large portion of his hires, most likely people that he would have never hired in the first place if he had spent a bit more time in the beginning.
I've fired someone before, and I'd do it again. But it was a horrible experience; and I would want to avoid that kind of experience, especially for 3-6 months.
One thing that gave me a lot of confidence was to set up a peer review system. Once I saw that the group had the same instincts I had, it was a no brainer. (Peer reviews are so much more interesting on many levels, actually. I don't know why this never occurred to any of my bosses.)
Other than this, the "one week trial period" proposed in Rework (http://37signals.com/rework/) seems like a good way to avoid a "several month realization of uh-oh". Has anyone ever tried this out?
From my own experience, the best team I ever worked on was one where we had a rigorous interview process... and fired 2 of the first 6 engineers, i.e., one third.
I say 1:5, which I feel is high, this number despite a rigorous technical interview process.
On a different note, another company that somehow started in small-town U.S. needed to expand their engineering staff. They looked in the Bay Area but the salary reqs were far too high so they settled on Portland. Got a team of engineers stood up in a satellite office. And then because of some minor personality conflicts and a lack of management skill failed to use them. This gave that team a bad reputation as "the team that sucks".
Now to be fair, they weren't the hottest rock-star coders in the world. But they could take a detailed spec and put out some reasonably solid work -- in other words, the absolutely normal, run of the mill developer. The problem was with the front office, not the engineers, they simply didn't know how to put together technical requirements that a remote site could follow. They conducted all of their engineering task assignments with daily, in-person staff meetings, verbally assigning tasks to engineers and writing down the task name in a development tracker (usually with lots of white board time).
A year later, the Portland team, unable to ever attend any of the daily, in-person, task assignments, and the front office unable to put together a decent set of specifications to send to a remote office, had no assignments, and a bad rep. The whole team was ultimately let go.
Employer-employee relationships differ from country to country but the above is I think a universal truth. Be a 'bad boss', hire and fire at will and you'll find that your employees will continuously be on the look-out to see if they can do better before you have a bad (pointy) hair day.
Treat them well and they just might amaze you in what they can do for you.
Managing people always was the part of the job that I dreaded the most, as the ceo of a relatively small company. The biggest reason for that was that it took time away from my 'first love', computer programming. But I hope that I never treated the employees of my company as cold and heartless as the article suggests, I'd be interested to hear his employees side of the story.
Different strokes for different folks, it is very well possible that this strategy will work for a certain style of CEO, in a given job-market and location, but I'm fairly sure that it would not have worked for me.
I'd rather spend a bit more time on the hiring side of things and get the right people on board than to go for a 'trial-and-error' approach like this and to have to go through the painful (for all parties) process of getting rid of a third of the new hires every six months.
I have a particular problem with the sentence:
> Your team thinks you suck if you don't have the chutzpah to fire.
That speaks to me of a CEO that is at heart a very insecure person.
You don't fire people to show you've got balls.
"Your team thinks you suck if you don't have the chutzpah to fire."
And that just makes no sense.
Firing bad people is in the other bit above, where it says:
"No, firing bad people improves the culture because it sets standards, and proves consequences. One bad apple does ruin the bunch."
Hiring bad people is what ruins the culture, firing them improves it back to what it was before you hired them, if you're lucky. Most times will never go back to what it was before.
If reading the bit out of context makes no sense, perhaps a different reading, such as suggested by parent comment(s) is indicated.
Then it would make more sense. But firing people is a step done with some restraint, bad apples get their chance to improve 'or else' and if it doesn't work out then the 'or else' gets activated, and presumably the whole team will be on board with that decision.
The last thing you want is to be seen as someone that fires people to prove that you do not suck.
Once a company gets to the point where people are being hired and fired by managers, churn becomes an additional chaos factor that people trying to do work have to deal with.
There is 'incompetent', but that usually comes with a specific field of competence, maybe the employee has different skills and can be given a new role where they're more productive and happy.
There is 'anti-social', this is a real problem and should probably have been caught at the hiring time, a person like this is going to have a hard time being a part of any team.
Then there is 'not in this team', if you have only one team then that's easy, but if you have more of them you might try a different one.
There are the 'loners', people that can't work with others but have to do everything their way, these are usually better suited to become entrepreneurs themselves (I had one guy like that working for me and I helped set him up to start his own business and he actually succeeded in an amazing way).
And so on. So even if you can't keep a bad person on the team there are a few more steps before you bring out the shotgun.
I've literally fired exactly one person, the reason was that he was starting up a competing service and at the same time approached our customers. That was reason enough for me for an on-the-spot termination when I found out.
Other than that we never had any issue that we couldn't resolve amicably or part on good terms without having to resort to firing someone outright.
Have a rigorous interview process where you try to hire only the best fit. If the new employee is a failure, have the ability to admit you made a mistake a correct it. Best of both worlds.
Firing a new hire is not a cheap process and it does affect your reputation/company morale.
This is oddly similar to the compile/run time distinction in bugs. You want to push as many of your bugs to compile time as possible (not-so-subtle plug for static typing) but it's impossible to have catch all of them in compilation; such is the nature of bugs. Similarly, you want to catch as many problems as possible in the interview process, but can't get all of them.
Straight, direct, clear and refreshing communication. I recommend you go through the other posts at http://www.fonality.com/blog/
Which is why in most companies poor performers get "promoted" to where hopefully they can't do too much damage. If you're lucky, they can be contained to writing reports that no-one reads. If you're not and someone forgets why they were promoted, then they might actually end up in charge of something, and no-one wins. Except for the HR department. They always win.
We've had lots of incidents in the past where older employees would play the "I have a health issue" card to avoid being fired. Just to avoid getting sued, the company would capitulate and "promote or move" them away from the manager who didn't want them.
Part of the problem is that as companies get bigger and their pockets get deeper, an entirely new class of employee enters which is low skill, highly cunning, and completely untrustworthy. Unfortunately, in my experience, most of these individuals always fit a certain profile: Middle Aged Men (50+) Low level of education
Most of these people are hired for two reasons: 1) Need someone for grunt work (support/maintenance) 2) Need someone that will accept a very low salary
Once a few incidents happen, HR and legal issues take over and begin the stranglehold on operational efficiency that infects large organizations.
If you're a startup, you're hiring people who understand the lack of job security. If you're a large company, there's no excuse for firing 1/3 within 6 months: you can move people around until they fit. If you're getting rid of more than 10% in the first 6 months, you're doing something wrong.
My thought: we should have a real safety net (including universal healthcare and a basic income that everyone gets, even the gainfully employed millionaires) and then allow companies to hire and fire whomever they want, because no one's life gets ruined by the loss of a job. But this would be a radical departure from the society we currently have.
I told that plenty that make it so difficult to fire a person that they have high youth unemployment rates (e.g. France), but the above three with a strong "Protestant work ethic" might work out well. Or the incentive structure, if a lifestyle on the dole is too good for too many people, might be disastrous in the long term.
I'm inclined to think the latter will be the outcome but wonder if we have any tests of the proposition.
Within about 50 years, due to technological advancements, we'll have 20-40% paid employment (not unemployment) and there'll need to be some sort of dole.
Personally, I think it would be great to have a society where people don't need to work. The people who only work because they have to wouldn't be working, which means that the people who are working are those with ambition and talent, and only those.
The wealth gained from the Republic's Third Punic War had an ultimately disastrous result in all sorts of ways.
That said, you're absolutely right, we will someday have a true post-scarcity society, although the near total suppression of real nanotech research in the last quarter century makes me leery of predicting any dates.
Start with this item at the end of the home page: Changing the narrative in the U.S.
In short, "the establishment", e.g. existing chemists appropriated the buzz Drexler created while not actually doing what he was promoting for the usual parochial reasons plus in many cases a genuine and legitimate fear of what his style nanotech will bring about.
I should probably vaguely mention that my PhD work was not entirely disconnected from the idea of fabricating devices by placing individual atoms in locations with sub-nm precision. I suppose I should be offended that nobody let me in on the fact that we're supposed to be suppressing that kind of work.
The bottom line is "where are the grants and research centers for Drexler style nanotech"? Either he's lying about this---I'll admit most of my info about this is from him or people in his orbit---or he's mostly right.
Or let me put it this where: when you graduate, where are you going to be able to go to work on "Productive Nanosystems" in his style? Name names, this should be something you're looking for or at least aware of, or can ask about tomorrow when you go into "work".
ADDED: I know it's "ridiculously hard", for if finances hadn't gotten in the way I would have most likely eventually gotten a Ph.D. in work "not entirely disconnected from the idea of fabricating devices by placing individual atoms in locations with" atomic precision in the '90s.
Same place as the grants and research centers into warp drives and unicorn husbandry?
However your appeal to authority (that authority being yourself) does not falsify what Drexler has said about this or his evidence.
One thing that happens is that some low-level jobs have high fluctuation. Especially as the government pays some additional money for some jobs in the first couple of months (which seems extremely absurd to me). So some clever employers fire their employees once the government subsidization has expired...
Britain probably qualifies to some extent, because employees cannot claim unfair dismissal if they were sacked before they'd been working for an employer for one year.
As far as I know (and I admit I don't really), don't they all make it hard to fire someone, at least after a trial period?
What about Denmark?
They're supposed to have a private sector that's way above average for Western Europe, but I don't know or remember about firing policies or if they have a dole.
Dole as in any able bodied man who isn't working can draw government payments that provide an acceptable level of living.
At will means anyone not in a contract can be fired at any time for any reason (well, you can disallow a few narrow ones like getting pregnant in most situations).
"“Lord of The Flies Meet Corporate America.”
Pros
Product works well and is fully supported by a highly skilled team. Some positions offer work from home.
Cons
Management plays favorites for their friends and plays immature games. Nothing you shouldn't expect from a company that had a fight club. Overall the upper management doesn't seem to care about their employees rather tech support or sales. Constant turn over in the sales department lead by myopic management team. You will love the atmosphere with your coworkers but despise the management for their lack of respect and unethical conduct.
Advice to Senior Management
Treat your employees with respect. You can not expect your customers and channel to respect you when you constantly cut good people from your team. I would advise the executive team to seriously look at their management who has regular turnover. Sometimes its the process not the person."
The "resources" angle is crucial. Large companies can afford to have a non-producer for 6 months and train him up to being able to contribute, and they generally should. Startups usually can't afford this.
Of course, this excludes the cases where a person is fired for doing something seriously wrong or unethical. But I imagine it's much easier to fire in those cases.
I'm pretty sure the abstraction bit is innate (I'm assuming they've passed high school math), and very sure I can't teach it nor is it my duty to. Pointers and recursion are not so bad (but again, in these sorts of situations I'm probably not in a position to get them up to speed on something so basic and so far reaching in effects (especially unsafe pointers)).
One quibble:
"It takes time to glean an employee's pithy attributes: work ethic, intelligence, attention to detail, enthusiasm, even personal hygiene."
You should be able to judge at least initial enthusiasm in your interviewing process or you're not doing a good job of selling your company or it's an impossible sales proposition. Either of which you should do something about at a high priority.
But I'll admit that sustained enthusiasm is what really counts and of course only time will tell WRT to that. And I'm not sure what you'd do with people who take some time to warm up to a situation (ADDED: well, make sure they've been enthusiastic about at least one prior job; if they're too young to have any/many and are already cynical you'd probably best pass on them :-).
For programmers you should be able to get a reading of intelligence and attention to detail in the interview as long as you do minimal testing (perhaps Fizzbuzz, my preferred 3 tests of reverse a linked list (pointers), recursive factorial and find error in this block of code, etc.).
Having them work out loud with you a relevant design problem is also good, although recognize that only 1/5 of programmers "get" abstraction (according to the Antipatterns book and my personal experience); if you need/can afford having programmers who don't get it, you'll want to gauge their ability to follow orders and "do it this way" "just because" the architect says so.
(There are potentially lots of slots in an organization including a startup for all sorts of competent people, e.g. look at the 2nd Coders at Work interview Brad Fitzpatrick, the Live Journal Founder. They had an older employee who produced awful code, but they loved him since his forte was quickly figuring out difficult integration problems which no one else liked to do or was good at. He handed them messy solutions filled with duct tape and bailing wire and they mined the interfaces from them and made clean versions that fit with their system.)
Anyway, my advice is to pay close attention to what this author says, just don't let it cause you to significantly relax your hiring system since hiring, working with and then firing duds is always debilitating for all concerned.
Today, I don't know what I'd do (besides ask them to do it with pointers anyway, pseudo-code is fine for this problem). Someone from a Javaschool might work out well, but they'll be lost in some harder debugging situations, so I guess I'd try to make sure they'll ask for help when it gets that messy and make sure I had some uber-programmers to support them (such as myself :-).
But I'm sure many fewer today, note that I started out with punched card FORTRAN "IV" on an IBM 1130 and then did a lot of UNIX on PDP-11s. Fortunately I was able to play with LISP starting a couple of years after that first experience.
Today the world is almost entirely different, e.g. it's hard to buy a processor that had less L1 cache than the max address space of those machines' macroarchitecture.
ADDED: Or as I like to say, echoing someone I forget:
Cache is the new RAM.
RAM is the new disk.
Disk is the new tape.
(SSD does't neatly fit into that....)
When I was doing this, groking pointers was required and functional programming unfortunately just wasn't an option. E.g. during this period LISP was anathema (even to the point where one project at the beginning of this decade died because it could only be done in something that productive but use of it was rejected for no good reason).
So my test was for understanding pointers as well as figuring out how smart they are at programming.
Plus as noted when things get ugly (e.g. in some debugging situations) groking pointers is required and as long as Johnny von Neumann's initial hack architecture rules that will remain true.
Today, I would most certainly take someone with "a good understanding of functional programming as a substitute for a good understanding of pointers", I'd just make sure a few also grok pointers and other low level stuff.
(I am so happy we have exited the Dark Age of Programming Languages.)