Sometimes, you read something that makes you want to take a long shower. The 48 Laws of Power, written by Robert Greene, and produced and “designed by” Joost Elffers (and what’s it say when a book’s producer/designer gets equal billing?) takes Machiavelli’s suggestions and the ethical dilemma he posed and eliminates the ethical dilemma.

Machiavelli expressed his dilemma in The Prince: “Any man who tries to be good all the time is bound to come to ruin among the great number who are not good. Hence a prince who wants to keep his authority must learn how not to be good, and use that knowledge, or refrain from using it, as necessity requires.”

Greene and Elffers say, “No one wants less power; everyone wants more.” “You will be able to make people bend to your will without their realizing what you have done. And if they do not realize what you have done, they will neither resent nor resist you.” “In fact, the better you are at dealing with power, the better friend, lover, husband, wife, and person you become.”

They figure everyone wants to increase their power, and always at someone else’s expense. This may be true in their world. In mine, most people want to optimize their power, not maximize it.

Powerlessness is a sorry state of affairs most of us try to avoid — true enough. Maximize your power, though, and you isolate and dehumanize yourself, substituting dry affairs for loving relationships, suspicion and manipulation for trusting friendships, and cold planning for the uninhibited enjoyment of life. Love and friendship require us to give others power over ourselves and vice versa.

On the other hand …

In your career you aren’t surrounded by friends. So while I don’t generally recommend “Keep[ing] others in suspended terror,” (Law 17), recognizing that your rivals do can prevent their achieving power over you. Nor should you “Use selective honesty … to disarm your victim,” (Law 12) for any number of reasons, not the least of which is an insufficient supply of naivete. If you’re naive enough to fall for it, though, your less scrupulous colleagues will manipulate you without much effort.

Some laws are just bad advice. Law 11, which advises you to “Learn to keep people dependent on you,” can change you from a peer to a subordinate in a hurry if you aren’t careful, and can prevent an employer from promoting you out of fear that what only you can do will no longer get done. If you’re irreplaceable, you’re unpromotable.

Other than its ethical repulsiveness, the biggest problem with this book is that some of its suggestions only work when everyone plays. “Get others to do the work for you, but always take the credit,” only works if people don’t confide in each other. Otherwise you can kiss Law #5, “So much depends on reputation — guard it with your life,” goodbye.

But … and it’s a big but … you can’t always avoid Machiavelli’s ethical dilemma, and even the most distasteful of these 48 “Laws” may be required to keep a bigger schmuck than you from taking over.

Sadly, you should own this book. Put it on your home (not office!) bookshelf, right next to Covey’s The Seven Habits of Highly Effective People and see if one of them bursts into flames.

“What operating systems have you used?” I asked a help desk applicant years ago. She pulled a paper from her purse and, referring to it frequently, recited a respectably long list. I literally didn’t know what to ask her next.

I’ve run across quite a few interviewing techniques over the years. I know of one company that surrounds the applicant with interviewers, creating an Inquisitorial atmosphere, to find out how the applicant responds under pressure. I’m pretty sure I’d fail this one – my response to this kind of pressure would be intense irritation.

Then there are the companies that use a battery of aptitude, psychological, and skills-inventory tests, on the theory that while you can fool an interviewer, you can’t fool a psychologist who’s never met you.

There’s the old standby, “What’s the worst mistake you ever made on the job?” My favorite answer: “I once chose an inferior grade of concrete on a construction project. Fortunately, the building collapsed while under construction so all we lost were a few welders.”

And of course, there’s the entrepreneur’s approach: Relying on gut instinct. This technique is remarkably effective – it infallibly selects the applicant with the best hair and handshake.

Overall, the two most effective techniques I know of are to have the applicant describe past successes in detail, and to “do the job in the interview” – a concept I learned from Nick Corcodilos of Ask the Headhunter fame (www.asktheheadhunter.com). By asking about past successes you find out whether the applicant is in the habit of succeeding, and what the applicant considers success to be. By having the applicant do the job in the interview – explaining a current situation and asking what he or she would do about it – you should get a good idea of how the applicant would do the job.

I’m adding a third technique to my arsenal. I discovered it by accident, interviewing that help desk applicant who had such amazing operating system expertise, and recently rediscovered it interviewing a vendor we were thinking of partnering with on a project: Ask a really easy question.

We’re not talking about questions with right or wrong answers, especially not questions where “right” means agreeing with the interviewer. We’re talking about questions that reveal whether the applicant, or the vendor if that’s who you’re interviewing, understands the subject area based on real-world experience.

If you’re interviewing a product vendor: “What are the key things we need to do when we implement your project so we get the business results we want?” Any vendor worth buying from should be expecting this question. You should get a crisp, well-thought-out, believable answer. If instead you hear a rambling discourse that meanders all over the conceptual landscape, or a too-brief, uncomfortable disclaimer coupled with a squirming look of discomfort, you can be confident you’re talking to the wrong company.

How about a systems analyst? “What’s the difference between building a new application and implementing a package?” Anyone who knows the business will speak comfortably and knowledgeably about the long list of differences between these two processes. The ones you don’t want will say, “It’s all pretty much the same: You figure out your requirements, come up with a solution, and implement it.”

By itself, the easy question technique won’t guarantee you make good hires. What it can do is tell you, in no more than five minutes, whether you’re wasting your time.