hiring

was

There's nothing magic about going to college on its own.

You seem to have ignored a lot of what your university teachers were trying to tell you, and I learned most of my electronics in the physics library w ithout any help from formal course work.

College is not useless - it's just that some people can manage to learn stu ff without too much personal help from teachers, so formal lectures aren't absolutely essential (though they can be decidedly useful, particularly if you take them seriously).

Quite how Google finds the - tolerably rare but very useful - people who ca n learn without being taught wasn't revealed by the article in "The Registe r" which displayed it's usual talent for failing to explore the interesting bits of their story.

If Google can find enough find-it-out-for-yourself staffers to have them ma king up 14% of some teams, they've found a way of looking at wider range of candidates than most organisations of their type, and presumably a way of winnowing these more numerous candidates more effectively.

The Register emphasises that Google's interviews used not too work too well for selecting potentially useful employees; the implication is that Google now runs better interviews, but presumably has to do a lot more of them.

Bill Sloman, Sydney

Sounds like they might be about to try graphology or phrenology next.

Depends what you are interviewing for I suppose. You do need to test if people have the skill set that they have claimed on their CV. Too many don't or have a much shallower understanding than they have claimed.

I particularly like the agency buzzword ads that say must have N years experience of "methodology that has only been going N-2 years".

We reckoned that someone who claimed to know Fortran inside out should be able to explain what a small piece of tricky code did or construct an efficient algorithm to solve a much simplified toy problem.

Even when you are careful you can still end up with problem people. Managing software engineers in the large is not unlike herding cats.

We have also had the odd electronics engineer recruited that couldn't solder to save their lives or thought transistors had infinite gain!

Hiring to sweatshops is big number game. Unless obvious handicaps and deformities, anyone is just as good as any.

VLV

"How many times do a clock's hands overlap in a day ?" How is that even a "trick" question, and how is the person who has no clue about answering it not useless?

Best advice for interveiwing (both sides) I have found is the Ask the Headhunter site.

Charlie

A correct answer to that question reveals that the interviewee can count.

"Pick a project that you really liked, and give us a 30 minute chalk-talk on it" tells you:

A: whether the interviewee stood on the sidelines answering clever but superficial questions instead of actually working,

B: whether the interviewee can communicate technical information accurately,

C: how much the interviewee will dive in and do what needs to be done vs. twiddling his thumbs while waiting for a manager to tell him in detail what to do,

etc.

was

"trick" question, and how is the person who has no clue about answering it not useless?

A 12 or a 24 hour clock?

If he remembers a circuit or a program in serious detail, then he probably designed it.

I like to work with people before I hire them. That's best if it starts as consulting or internship, but if that's not practical, spend a day in front of a whiteboard designing something serious together.

Good design engineers are sometimes visual and not very verbal. A written test or an interview may not show how his brain works.

None. My clocks are all digital.

Many years ago, I had the displeasure of doing some work for a company (name withheld) that apparently was very interested in teamwork. Employees were selected mostly for their ability to work as a team, and possibly on how well they got along with superiors and inferiors. Technical expertise seemed to be assumed and guaranteed by the resume and diploma.

The problem was that nothing was moving on the project. Decisions were not being made, nothing was being expedited, and everything seemed to be delayed or on hold. Despite having almost finished my part of the project, I was somehow blamed for the delays, which prompted my unpaid visit to corporate headquarters.

What I found was a ship without a rudder. There was no leadership at any level. There was no sense of urgency. In engineering, I saw more paper in status reports than in test reports. I attend what turned into my first and last 3 hour engineering meeting. I did my best to give management a very necessary hint, but as an outsider, I was ignored. The company self destructed a few years later, and was sold off piecemeal.

That's what happens when you hire on the basis of "team players". Without a "super star", nothing gets done. In a real company, there's exactly one person in engineering, that tends to be the source of great solutions and who makes thing happen. That person is invariably surrounded by lesser individuals, who are there to assist the "super star" and not get them bogged down in trivia. I've seen that in about

The problem is that hiring for such a "super star" versus the rest of the staff is quite different. The "super star" usually has enough personality issues, bad habits, and offensive manners to become a problem for at least one person in the interview chain. It's a major miracle such people ever get hired. The few that I know personally, either discovered that they had talent after being hired for something completely different at the company, or were inherited from another company during a merger or acquisition. I've never seen a "super star" designer hired during an interview process (though it might be possible).

What the various popular interview methods and resume decoders offer is a way to hire commodity engineers and staff. People that will do adequate work, in an adequate manner, and with a minimum of headaches and hassles. Such people are highly desirable and necessary. They will not produce the conceive of the next big thing, but are very necessary to getting someone elses big thing out the door. So, what is Google doing asking questions that are appropriate for hiring a "super star", when they seem to be hiring far more commodity engineers and programmers? Dunno.

I don't have a magic formula for hiring. As with stocks, past performance is not a guarantee of future results. Place a good performer in a new situation, and they could easily fall apart. I worked with one decent engineer, who wend from a 10 minute commute, to a 2 hr traffic clogged ordeal. He didn't do so well when it took him several hours to recover from the morning commute, and an hour to brace himself for the evening ordeal. Similarly, a former good performer may have utilized company resources that are no longer available. People that are good at finding mistakes are almost as valuable as those making the mistakes.

Whatever the method, the interview should be conducted in an approximation of the environment in which they are expect to work. For a small company, I would be tempted to ask an engineer to work through the design of a trivial product, such as a 12v to 5v regulator, from conception, through design, into PCB layout, packaging, to manufacturing, including certification, testing, QA, parts procurement, and maybe even shipping. My guess(tm) is that this would take all day and would certainly highlight an engineers experience with all the various aspects of the company and its suppliers and vendors. Simple things, like the size of a pilot run, itemization of government agencies that require certification, familiarity with common procedures, and knowledge of vendors, are important. That's because on a typical 3-6 month project, the actual design was done in a few days, while the rest of the project revolved around non-design functions. For Google, that's difference between hiring someone who expected to live in their cubical cranking out code, or someone that will interface with the users, vendors, and other departments effectively. Asking trick questions isn't going to work.

(My appologies for the long rant, but I showed up 1 hr early for an appointment had some time to burn).

I agree, broadly. Consulting is great because it allows you to select somewhat less critical projects which are still helpful and allows you to see into the development process as often as you want, as well as the final results in the end. Keeps the committed investment lower, too. An interview just can't get you there.

The serious whiteboard design time is also decent. I've seen it used before (on me.) I flew down to the bay area for a new startup and spent the entire day there with a team interview. They basically made me think about their central problem to solve -- the one they were actually leveraging as their product value -- and then next day I got an offer from them. Problem was, the pay offer was very much less than I was already making working far less hard than I would with them. Made no sense to me. So I declined. But I got a chance to see a well-handled process similar to what you are suggesting.

Yes. And there may be difficulties because of that in communication both ways with a real team you have in place, already. But your methods above work through that so you have a much better idea in the end.

I think the contract method is nice and bite-sized and works through enough of the kinks that you have a pretty good idea what you would be buying into if you made a commitment.

Jon

There have been many places where I have consulted where I had to abuse the paperwork shuffler before a large audience, usually with upper management present >:-}

I always win, because I always deliver >:-}

Of course I have many enemies. I lost a possible project last week because a little POS PhD tried to trip me up, made a gross mistake, and I showed him up. Unfortunately he had enough pull to nix me. But, if the usual situation prevails, in a year they will be totally hosed, will require my help, and my price will go up ;-)

I AM a team player, I do the whole design and the rest of the "team" does the grunt work >:-} Design by committee always fails. ...Jim Thompson

A few (many...) years ago, I had the pleasure of working for a manager that knew his stuff. We were doing hardware for a toll road, and it was a virtual company; he was the only one directly employed by the company the rest of us were all 'consultants.'

We were all super star designers in our own areas, it felt like. Many an enjoyable morning was spent sitting in his office, or our cube farm going over some point of design that we needed to solve. There were only four or five of us, but we didn't run into a single problem we couldn't handle. An hour or two on a white board, then an afternoon or two documenting the details of the solution.

Of course, they fired all of us (and him!) as soon as they could. We made the other managers look bad, so they sandbagged him.

GenRad closed the whole Phoenix Division (portable tester products) because we were the only division that made a profit... and offended corporate by giving bonuses ;-) ...Jim Thompson

I think I'm just in a contrary mood today.

I have been on committees that made design by committee work, and work well. Design by committee works if the committee is small (no more than one member per finger of one hand), if every member is both worthy of respect and respects all of the others, and if there's a committee chair (AKA "the project manager") who has veto power for those rare occasions when someone goes off the rails (which, I have to admit, is sometimes me

-- I try to be graceful about it when I'm seized by the collar and told to desist).

But yes -- design by committee can result in some pretty horrid nightmares, followed shortly by finger-pointing by committee.

Design by committee only works with players chosen by skill-set: one analog guy, one digital guy and one layout guy. In my usual case, my buddy (*) in Columbus does both of the latter two functions... so we're a committee of two ;-)

We've done several dozen chips together over the past 20 years like that... every one of them a success on first time out of the foundry.

(*) Contact information upon private inquiry. ...Jim Thompson

It's true that where it's worked for me it's been a committee consisting of the technical leads (electrical, mechanical, software and possibly systems) plus a project manager.

Even then, as soon as someone comes into the room intent on proving that he's got bigger balls than anyone else, the whole scheme falls apart.

If he remembers a circuit or a program in serious detail, then he probably designed it.

I like to work with people before I hire them. That's best if it starts as consulting or internship, but if that's not practical, spend a day in front of a whiteboard designing something serious together.

Good design engineers are sometimes visual and not very verbal. A written test or an interview may not show how his brain works.