Comments: Can you think out of the blender? and other oddball questions (Part 2)

"This is the big picture, actually written a bit too narrowly. Traditional HR doesn't work well at all."

Is this proposition also too narrow? Perhaps we could say the modern corporation doesn't do well at all. After all, the Director of HR must be making someone happy, and that person reports to the CEO. None of them care to make any "line" employees happy. They only care to make shareholders happy in limited, specific ways, and with modern Golden Parachute Syndrome only for limited periods.

But that wider indictment is contradicted by reality: if corporations are so bad why do we have so many of them? Why do so many people work at them? For a full accounting, we'd probably have to condemn most of society. Instead, let's identify the specific tasks at which corporate HR does excel, and...

...well I'm drawing a blank there. This area could use more study.

Posted by Jess at April 23, 2013 11:16 AM

You're not the only one grappling with recruitement:

How Big Data Is Playing Recruiter for Specialized Workers
Jim Wilson/The New York Times

Jade Dominguez, 26, never went to college, but was hired by Gild, a start-up, after its algorithm put him atop a list of programmers.
Published: April 27, 2013

WHEN the e-mail came out of the blue last summer, offering a shot as a programmer at a San Francisco start-up, Jade Dominguez, 26, was living off credit card debt in a rental in South Pasadena, Calif., while he taught himself programming. He had been an average student in high school and hadn't bothered with college, but someone, somewhere out there in the cloud, thought that he might be brilliant, or at least a diamond in the rough.

"The traditional markers people use for hiring can be wrong, profoundly wrong," says Vivienne Ming, the chief scientist at Gild since late last year.

That someone was Luca Bonmassar. He had discovered Mr. Dominguez by using a technology that raises important questions about how people are recruited and hired, and whether great talent is being overlooked along the way. The concept is to focus less than recruiters might on traditional talent markers -- a degree from M.I.T., a previous job at Google, a recommendation from a friend or colleague -- and more on simple notions: How well does the person perform? What can the person do? And can it be quantified?

The technology is the product of Gild, the 18-month-old start-up company of which Mr. Bonmassar is a co-founder. His is one of a handful of young businesses aiming to automate the discovery of talented programmers -- a group that is in enormous demand. These efforts fall in the category of Big Data, using computers to gather and crunch all kinds of information to perform many tasks, whether recommending books, putting targeted ads onto Web sites or predicting health care outcomes or stock prices.


kr, Twan

Posted by How Big Data Is Playing Recruiter for Specialized Workers (from Twan) at April 29, 2013 03:38 AM

David Lewin, a professor at the University of California, Los Angeles, and an expert in management of human resources, said that asking what someone could do was an important question, but so was asking whether the person could accomplish it with other people. Of all the efforts to predict whether someone will perform well in an organization, the most proven method, Dr. Lewin said, is a referral from someone already working there. Current employees know the culture, he said, and have their reputations and their work environment on the line. A recent study from the Yale School of Management that uses Big Data offers a refinement to the notion, finding that employee referrals are a great way to find good hires but that the method tends to work much better if the employee making the referral is highly productive.

For his part, Dr. Lewin is skeptical that an algorithm would be a good substitute for a good referral from a trusted employee.

Posted by People like us! at April 29, 2013 04:01 AM


Employee referrals are a very common means by which firms hire new workers. Past work suggests that workers hired via referrals often perform better than non-referred workers, but we have little understanding why this may be. In this paper, we demonstrate this is because referrals allow firms to select workers better-suited for particular jobs. To test our model, we use novel and detailed productivity and survey data from nine large fi rms in three industries: call-centers, trucking, and high-tech. Referred workers are 10-30% less likely to quit and have substantially higher performance on rare "high-impact metrics" (e.g. creating patents and avoiding work accidents), despite having similar characteristics and similar performance on non-rare metrics. To identify the source of these behavioral differences, we develop four new statistical tests, all of which indicate that referrals benefit firms primarily by selecting workers with a better fit for the job, as opposed to referrals selecting workers with higher overall quality; to referrals enabling monitoring or coaching; or to it being more enjoyable to work with friends. We document that workers refer others like themselves, not only in characteristics but in behavior (e.g. unsafe workers refer other unsafe workers), suggesting that fi rms may gain by incentivizing referrals most from their highest quality workers. Referred workers achieve substantially higher profi ts per worker and the diff erence is driven by referrals from high productivity workers.

Posted by "The Value of Hiring through Referrals," April 24, 2013, Burks, Cowgill, Homan, Housman at April 29, 2013 04:12 AM

The entire notion that a college degree "signals" something valuable to employers is breaking down. In the good old days, earning a college degree proved that a student was hard-working and conformist--just what hierarchical corporations and government agencies want in employees. (The "signaling" value of a diploma is based on work by economist Michael Spence in the 1970s. In general, the signal indicates an attribute whose value is correlated with the difficulty and cost of the signal: the harder it is to get a degree, the greater the value of the signal it sends.)

But in an economy in which education credentials are in over-supply, that signaling mechanism is running up against a basic reality: a degree accredits very little about the student's knowledge, problem-solving skills or professionalism. A degree is simply a proxy of knowledge, not evidence of knowledge or useful skills.

Indeed, the study Academically Adrift: Limited Learning on College Campuses concluded that "American higher education is characterized by limited or no learning for a large proportion of students."

Signaling an ability to grind though four or five years of institutional coursework is no longer enough; the signaling needed to indicate an ability to create value must be much richer in information density and more persuasive than a factory model diploma.

A resume is equally thin on information that accredits a worker's knowledge, useful skills and professionalism. A resume is a public-relations summary that everyone knows has been tailored to present the candidate in the best possible light. And precisely how useful and trustworthy is PR in any setting?

Put yourself in the shoes of a hiring manager or potential collaborator: there is precious little useful information in either a diploma or a resume. As a result, human resources departments have been tuned to eliminate as many candidates as possible by signal-based winnowing rather than by the collection of useful information on the skills, knowledge and professionalism of the potential employee/collaborator.

Posted by How To Get a Job Despite the Economy - Charles Hugh Smith at April 14, 2014 05:31 PM

....... "This reminded me the years spent at large industry players like THALES in France or SPC Corp. in the US. Large companies often have a "postdoc" policy for recruiting R&D staff. University alumni often hire pals, people that look like them, or at least candidates with a common background."

Posted by Trustleap at November 7, 2014 09:25 AM

I've been self-employed for the past three years. Though I did spend my first year out of college working for a three person, now-defunct startup, I've never had a typical 9-5 (or more like 10-8 nowadays) and to be honest, never really wanted one. Lara Schenck, LLC is a profitable business, and every day I do work that is enjoyable and challenging. I make my own hours, take vacations when I want to, and run everything on my terms.

While that's all awesome, what you don't get from working independently is the team experience. I base my work on teaching technical literacy to non-technical designers and content producers so that they can better communicate with developers. The theory is that if a designer understands why it's a bad idea to request 18 fonts, and if content producers know why it's not trivial to edit the titles of a set of related posts, life will be easier for everyone. At least that's my theory, and the assumption on which I've developed my business.

Lately though, in a bout of the good 'ol impostor syndrome, I've been feeling like, wait, how can I be telling people how to work on teams if I've never really worked on one? I've always been the 'Lead UI/UX/Visual/Web/Front-end Designer-person-thing', and have never worked for a larger company with separate teams for product, UX, marketing, content, frontend, backend, etc.

So I felt the urge to look for a job, and a seemingly perfect one fell into my lap. It was for an awesome company, and it sounded right up my alley skill-wise. The title was 'UX Engineer/Interaction Designer'. I usually balk at the the term "engineer" (perhaps for good reason) but considering the presence of "designer" and the nature of the job post, I wasn't too bothered.


Posted by Tales of a Non-Unicorn: A Story About The Trouble with Job Titles and Descriptions at August 11, 2015 06:29 AM
Post a comment

Remember personal info?

Hit Preview to see your comment.
MT::App::Comments=HASH(0x55fad6fa6d28) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/ line 125.