interviewing...

[RichD]

When you interview job candidates, you pose standard
problems, of circuits, PSpice, maybe Mathcad, etc.
Textbook stuff, you expect he knows, reviewing his resume.

Microsoft and Google are famous for posing brain twisters,
stuff \"outside the book\" (if any exists, nowadays with the net).
Do you do this? The obvious idea is to test for originality.
How much weight do you place on the responses?

--
Rich

 

[Don Y]

On 4/13/2022 1:02 PM, RichD wrote:

When you interview job candidates, you pose standard
problems, of circuits, PSpice, maybe Mathcad, etc.
Textbook stuff, you expect he knows, reviewing his resume.

Microsoft and Google are famous for posing brain twisters,
stuff \"outside the book\" (if any exists, nowadays with the net).
Do you do this? The obvious idea is to test for originality.
How much weight do you place on the responses?

We \"test\" to see how well the candidate can explore the problem
space. Folks who rush to a solution often miss on identifying
important (or \"valuable\") criteria/flexibility in their solutions.

\"Originality\" doesn\'t necessarily equate with competency.

 

[Grant Taylor]

On 4/13/22 3:32 PM, Don Y wrote:
> \"Originality\" doesn\'t necessarily equate with competency.

I completely agree. I\'m not looking for anything original by any
stretch of the imagination.

I am looking for something that causes the candidate to think for a few
minutes so that they can demonstrate their understanding of the problem,
how to possibly solve the problem, and what solution they come up with.

I don\'t even /require/ that the candidate have a fully fleshed out
solution. Especially if they don\'t because of an artificial time
constraint. If the candidate can demonstrate that they understand the
problem, can come up with a solution, and produce work towards the
solution, then they will get at least /some/ credit for the question.



--
Grant. . . .
unix || die

 

[Dave Platt]

In article <t37fgn$f62$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:

On 4/13/2022 1:02 PM, RichD wrote:
When you interview job candidates, you pose standard
problems, of circuits, PSpice, maybe Mathcad, etc.
Textbook stuff, you expect he knows, reviewing his resume.

Microsoft and Google are famous for posing brain twisters,
stuff \"outside the book\" (if any exists, nowadays with the net).
Do you do this? The obvious idea is to test for originality.
How much weight do you place on the responses?

We \"test\" to see how well the candidate can explore the problem
space. Folks who rush to a solution often miss on identifying
important (or \"valuable\") criteria/flexibility in their solutions.

+1

When I do these sorts of interviews, I\'m not (usually) looking for
domain-specific knowledge. Rather, I\'m looking for overall problem-
solving skills - and a big part of that is \"problem _defining_
skills\".

A very important first step (for the interviewee) is to make certain
that they understand the problem. What\'s being asked for? What are
the requirements? What is must-have vs. nice-to-have? What are the
must-not?

Somebody who can \"read back\" the problem as-stated (in their own words
and interpretation) and show that they understand what was asked for,
gets points... \"active listening\" skills like this are a real asset.
[I credit my wife for teaching me how important this is, and how it\'s
done - she\'s a graduate psychotherapist and this sort of skill is
critically important in her work.]

Someone who can pick up on ambiguities in the requirements and asks
for clarification gets points. Someone who states what they\'re
assuming (and says \"correct me if I\'m wrong here\") gets points.
Someone who lets me know where their personal expertise and skills can
cover, and where these end (\"I\'m on new ground and thin ice here\")
gets points.

Somebody who jumps in immediately to a proposed solution, without
doing the above... not so much. That\'s fairly common and foregivable
in rather-junior people (who want to show what they know) but I
don\'t care to see it in someone at the senior-designer level. It\'s
too easy (and expensive) for a project to get off-track due to
incorrect assumptions... the more senior the eager-beaver, the more
of the project that can be misdirected.

I don\'t go in for \"brain teasers\" or trick questions... those don\'t
necessarily correlate well to real engineering problem-solving.
Rather, I try to probe with real engineering problems which are
outside of the candidate\'s specific work experience and direct skill
set, but where there\'s a similar level of general technical expertise
and problem-solving ability required. I don\'t expect people to come
to a working solution in cases like these (although it\'s nice to see
it happen), but I want to see how they build their logical framework
to support a design.

Google _was_ notorious for brain-teaser problems, years ago, but I
understand that this approach is deprecated there nowadays.

 

[Dennis]

I completely agree.  I\'m not looking for anything original by any
stretch of the imagination.

I am looking for something that causes the candidate to think for a few
minutes so that they can demonstrate their understanding of the problem,
how to possibly solve the problem, and what solution they come up with.

I don\'t even /require/ that the candidate have a fully fleshed out
solution.  Especially if they don\'t because of an artificial time
constraint.  If the candidate can demonstrate that they understand the
problem, can come up with a solution, and produce work towards the
solution, then they will get at least /some/ credit for the question.

I had a friend that years ago had a job interview with one of the
minicomputer manufactures. At that time they still sent source code with
the systems and he would go over it - particularly when there seemed to
be problems. At the end of the interview with the operating system
manager he was asked if he had any questions. He said yes - he couldn\'t
understand a particular part of the OS and thought it was a problem.
They talked a bit more. The manager had one of the programmers bring in
the source code. The manager and programmer looked at the code a bit and
then told my friend that there was a problem and they would have to fix
it. He accepted the job offer.

 

[Don Y]

On 4/13/2022 4:27 PM, Dennis wrote:

I had a friend that years ago had a job interview with one of the minicomputer
manufactures. At that time they still sent source code with the systems and he
would go over it - particularly when there seemed to be problems. At the end of
the interview with the operating system manager he was asked if he had any
questions. He said yes - he couldn\'t understand a particular part of the OS and
thought it was a problem. They talked a bit more. The manager had one of the
programmers bring in the source code. The manager and programmer looked at the
code a bit and then told my friend that there was a problem and they would have
to fix it. He accepted the job offer.

I was looking at a consulting gig many years ago -- for an \"electronic door
lock system\" (think hotels, etc.).

I was given a brief tour of the facility which ended at their prototype
of the system (a sample door, with lock, and the \"front desk\" equipment
that manages the \"keys\").

I was given a brief/cursory demo and asked if I could \"play\" with it.
I stepped up to the console and selected \"Grand Master\" (each key exists
on several levels -- so the maintenance guy can have access to all of
the rooms in building A, the maid have access to the rooms on the first
floor, the guest have access to THIS room, etc.).

I was very deliberate in making sure my host could see what I was doing.
(He was very encouraging, thinking I had never seen the system before now.)

I then reached over and unplugged a cable -- which got a bit of a reaction
from my host. Then, proceeded to make 3 \"Grand Master\" keys. Then,
reconnected the cable and hit \"Cancel Operation\". Then, let my host
notice that the system had no record of the three FUNCTIONAL keys -- that
I handed to him!

Ooops!

 

[Don Y]

On 4/13/2022 4:04 PM, Dave Platt wrote:

In article <t37fgn$f62$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:

We \"test\" to see how well the candidate can explore the problem
space. Folks who rush to a solution often miss on identifying
important (or \"valuable\") criteria/flexibility in their solutions.

+1

When I do these sorts of interviews, I\'m not (usually) looking for
domain-specific knowledge.

Exactly. Most of the projects/industries with which I\'ve been
involved were \"atypical\" and most of the added value came NOT
from how well you could design a circuit, build a mechanism
or code an algorithm but, rather, from how well you could \"grok\"
the actual application domain.

Rather, I\'m looking for overall problem-
solving skills - and a big part of that is \"problem _defining_
skills\".

Yes.

A very important first step (for the interviewee) is to make certain
that they understand the problem. What\'s being asked for? What are
the requirements? What is must-have vs. nice-to-have? What are the
must-not?

More importantly, what *assumptions* is the \"problem presenter\"
not voicing (and, possibly not AWARE of!) as well as what assumptions
will the \"problem solver\" *bake* into his solution -- that might not
be merited or might LIMIT the solutions he can envision.

Somebody who can \"read back\" the problem as-stated (in their own words
and interpretation) and show that they understand what was asked for,
gets points... \"active listening\" skills like this are a real asset.
[I credit my wife for teaching me how important this is, and how it\'s
done - she\'s a graduate psychotherapist and this sort of skill is
critically important in her work.]

Someone who can pick up on ambiguities in the requirements and asks
for clarification gets points. Someone who states what they\'re
assuming (and says \"correct me if I\'m wrong here\") gets points.

But, there are issues that go beyond simple assumptions.

\"What are your SIZE constraints?\" etc.

\"Does the solution have to be ELECTRONIC?\"

\"Who is gong to be using this?\"

\"What is the expected lifespan of the <whatever>?\"

Someone who lets me know where their personal expertise and skills can
cover, and where these end (\"I\'m on new ground and thin ice here\")
gets points.

AFAICT, the only \"past experience\" that has ever been useful is their
*process*. You\'ve likely never designed (nor imagined!) one of <these>...

A group with which I am affiliated has a ~50K sq ft warehouse. The
\"inventory\" changes, RADICALLY, from week to week. One week it may
have thousands of computers... the next, hundreds of hospital beds
(occupying the space that the computers had occupied previously).

Keeping track of this inventory is tedious because it is so varied.
And, because they rely heavily on volunteer labor. There\'s nothing
you can use to ensure folks \"do the right thing\" when you\'re not
paying them, etc.

A guy \"solved\" this problem with a fancy database and web-based portal.
Must have been hundreds of hours gathering up the hardware, writing the
code, etc.

And, no one used it.

Because the data entry chore was HUGE. And, getting someone to
VOLUNTEER their time to type in all that crap -- and have someone
with that \"responsibility\" available 6 days a week -- just wasn\'t
gonna happen. He failed to COMPLETELY understand the problem
and came up with a solution that *he* could implement and \"use\"
(though I notice he didn\'t volunteer to do all the data entry!)

Some years later, I came along and said \"Why don\'t we have...\"
\"We already *had* a system. No one used it.\" Yada yada yada.

I designed a solution where every \"thing\" (\"of interest\") was tagged
with a unique barcode label. I printed sheets of these (self-adhesive)
in numerical sequence. If 1 -- or 397 -- got lost... <shrug> They
are just UNIQUE IDENTIFIERS so any one is just as \"good\" as any other!

When you \"used\" a label, you gave it meaning. \"37 is the identifier
for Don Y\". \"38 is the identifier for this hospital gurney\". \"39
is the identifier for room 101\". \"40 is the shipping manifest for
the May 2022 Guatemala shipment.\" etc.

So, scan the barcode on my \"badge\" and the system knows \"this particular
wifi barcode scanner is being used by Don Y.\" (because the definition
of \"item 37\" is that of \"staff\") Scan the barcode on the gurney and the
system knows Don Y is about to do something with that gurney. Scan the
barcode on the door to room 101 and the system knows Don Y has stored
*that* gurney in room 101 (at 12:47PM on April 12th) -- even if the other
gurneys are stored in 12 different places!

If Jerry (identifier 105) moves the gurney to some other room, he
will undertake similar actions and the system will know the new
location for *that* gurney (along with who moved it, when, etc.).

When Don Y wants to gather up all the gurneys to ship to Guatemala,
the system can tell him where each of them are located (no need for
them all to be in a common location!). He can type a description *or*
find a similar item and search for \"more of these\". He can then \"move\"
them to the \"shipping manifest\" to signify that they will be on a
truck/boat soon (so, trying to locate them in the warehouse is a
wasted effort).

[If he runs out of space in the shipping container, he can scan the
barcode on the gurney as he removes it and scan the new location to
\"return\" it to inventory]

You can verify your inventory at any time -- just by walking through the
facility and scanning an item\'s barcode, then the location in which it
is encountered. It\'s not even an \"inventory update MODE\"; it\'s just
\"normal mode of operation\"!

Note that you can *train* someone to use this \"user interface\" in
a matter of minutes. So, you don\'t have to \"invest\" much training
in your volunteer staff.

And, you can get folks who are developmentally disabled to contribute,
meaningfully, because they don\'t have to deal with a keyboard, computer,
etc. Just \"point\".

This isn\'t significantly different (development effort) than the previous
\"classical\" approach to managing data. You just have to think a bit
about the UI devices and the *users* who will be employing them! The
previous solution wasted effort on technology instead of understanding
the problem space.

And, the \"powers that be\" were equally at fault because their assumptions
(as to WHO would be using this) were so ingrained that they never thought
to give voice to them! \"Hey, make sure Tommy will be able to use whatever
you put together...\"

[Some years later, I was in a furniture warehouse and saw that they used
a similar approach to keeping track of where items were located. No need
to arrange to have all of the \"sofas\" in aisle 27, \"lamps\" in aisle 28,
etc. If you want something, let the machine tell you where to find it;
relying on some bogus system that makes you feel good that you can commit
thins to memory is hopelessly outdated!]

Somebody who jumps in immediately to a proposed solution, without
doing the above... not so much. That\'s fairly common and foregivable
in rather-junior people (who want to show what they know) but I
don\'t care to see it in someone at the senior-designer level. It\'s
too easy (and expensive) for a project to get off-track due to
incorrect assumptions... the more senior the eager-beaver, the more
of the project that can be misdirected.

Exactly. And, the more \"ego\" at stake.

I once asked a colleague who had a considerable role in hiring what
he thought of the \"youngsters\". He shrugged -- a *visible* \"meh\".
His only comment: \"They\'re FAST!\"

Sure! They don\'t yet know all the things that they don\'t yet know! :>
(i.e., WHY that solution isn\'t going to work -- even though it seems
like it *should*. They have to stumble onto the questions that they
should have asked up front...)

I don\'t go in for \"brain teasers\" or trick questions... those don\'t
necessarily correlate well to real engineering problem-solving.
Rather, I try to probe with real engineering problems which are
outside of the candidate\'s specific work experience and direct skill
set, but where there\'s a similar level of general technical expertise
and problem-solving ability required. I don\'t expect people to come
to a working solution in cases like these (although it\'s nice to see
it happen), but I want to see how they build their logical framework
to support a design.

An interview is a lousy environment to assess a person\'s skillset.
The power dynamic is horribly skewed. The interviewer likely has
preconceived notions of what he wants. The applicant focused on
getting the offer -- and not whether or not he actually WANTS the
offer. etc.

I want to see an applicant that is *interested* in the problem space
and approaches it in a way that suggests he might have \"good discipline\"
in approaching *future* problems (which I can\'t yet imagine)

Some firms look for \"personality issues\" -- especially those that require
large \"team\" efforts (lone wolves contraindicated, there). Likewise,
some require \"self starters\" -- folks who are resourceful and know how to
get the resources/supplies that they *might* need.

Google _was_ notorious for brain-teaser problems, years ago, but I
understand that this approach is deprecated there nowadays.

 

[Rich S]

I havent interviewed in a long while, but my
simple point is, do they show any passion
or enthusiasm for the job. That, alone,
seemed rare. If they asked a lot of on-point
questions - no matter how naive - that was
usually a very good indicator,,
regards, Rich S.

 

[Phil Hobbs]

RichD wrote:

When you interview job candidates, you pose standard
problems, of circuits, PSpice, maybe Mathcad, etc.
Textbook stuff, you expect he knows, reviewing his resume.

Microsoft and Google are famous for posing brain twisters,
stuff \"outside the book\" (if any exists, nowadays with the net).
Do you do this? The obvious idea is to test for originality.
How much weight do you place on the responses?

--
Rich

I interviewed a few folks when I was at IBM, but never did any quiz
questions.

BITD I got asked a couple of relatively memorable ones. Interviewing at
HP Labs in Palo Alto, they asked me to derive the Fresnel formulae for
reflection of a plane wave at a dielectric interface.

I said, \"You don\'t want to sit and watch me go through a bunch of
algebra, but I\'ll tell you how the calculation goes\", and then explained
about how phase matching at the boundary gives you the reflected and
transmitted k vectors, and the patching conditions for tangential E and
perpendicular D (*) give you a 2x2 matrix equation for the transmitted
and reflected field amplitudes. They were happy.

The other one was at Tektronix in Beaverton OR. (This was in 1987, when
at least some of their legendary vertical amp guys were still active.)
One of them (I think it was Thor Hallen) drew a circuit with a couple of
PNPs and asked me to figure out what it did.

The biasing was impossible--there was no way it would do anything
useful. I said something like, \"Well, at AC it would do X, but at DC it
makes no sense because the biasing is all wrong.\"

Turned out it was a ramp generator based on ancient germanium PNPs that
were so leaky that their base currents went the wrong direction. IIRC
it was supposed to be able to start up regardless of how leaky they were.

They weren\'t expecting anybody to get that in 1987--they just wanted to
see how folks approached the problem.

When I interviewed folks at IBM, mostly I asked them to tell me about
something they\'d built, and then we\'d discuss it. The ones who were
excited about showing off their mudpies and could answer fairly probing
design questions got the Good Housekeeping seal.

Cheers

Phil Hobbs


(*) or equivalently tangential B and perpendicular H.

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[server]

On Wed, 13 Apr 2022 13:02:45 -0700 (PDT), RichD
<r_delaney2001@yahoo.com> wrote:

When you interview job candidates, you pose standard
problems, of circuits, PSpice, maybe Mathcad, etc.
Textbook stuff, you expect he knows, reviewing his resume.

Microsoft and Google are famous for posing brain twisters,
stuff \"outside the book\" (if any exists, nowadays with the net).
Do you do this? The obvious idea is to test for originality.
How much weight do you place on the responses?

We did two Zoom interviews today. We talked about what we do, what
we\'re looking for, and asked the guys what they like to do. One was an
obvious non-fit to all of us; he said it first, so we parted happy.

The other looks promising, so we\'ll fly him out and get more serious,
whiteboard some circuits and architectures maybe. My interview
technique is \"let\'s design something together.\"



--

I yam what I yam - Popeye

 

[Don Y]

On 4/13/2022 6:44 PM, Rich S wrote:

I havent interviewed in a long while, but my
simple point is, do they show any passion
or enthusiasm for the job. That, alone,
seemed rare. If they asked a lot of on-point
questions - no matter how naive - that was
usually a very good indicator,,

Agreed.

\"Synthetic\" problems are likely not a good indicator
of how they will approach the *real* \"work\".

Like hypotheticals about wombats crossing roadways...
(unless you\'re particularly fond of wombats, how much
are you going to invest in exploring that problem space?)

 

[boB]

On Wed, 13 Apr 2022 18:44:26 -0700 (PDT), Rich S
<richsulinengineer@gmail.com> wrote:

I havent interviewed in a long while, but my
simple point is, do they show any passion
or enthusiasm for the job. That, alone,
seemed rare. If they asked a lot of on-point
questions - no matter how naive - that was
usually a very good indicator,,
regards, Rich S.

Yes ! Attitude and passion counts a LOT !

boB

 

[Martin Brown]

On 13/04/2022 21:02, RichD wrote:

When you interview job candidates, you pose standard
problems, of circuits, PSpice, maybe Mathcad, etc.
Textbook stuff, you expect he knows, reviewing his resume.

Microsoft and Google are famous for posing brain twisters,
stuff \"outside the book\" (if any exists, nowadays with the net).
Do you do this? The obvious idea is to test for originality.

Most regular interviewers have their own favourite pet questions.

Discussing the right answers online would defeat the object so they
don\'t stay useable for long in this age of everything on social media.

How many zeroes does 100! have in its decimal representation is one such
that has been popular in recent years.

> How much weight do you place on the responses?

Watching how they approach an unfamiliar problem can be a sufficient
guide to do they have what it takes. Engineering can get away with an
answer that whilst not exactly right is \"good enough\" for practical
purposes.

A pure mathematics course would expect the right answer (and quickly).

You have to know what characteristics you are recruiting for to pick the
right test question(s) for the position if you are playing this game.

Whether the individual will fit in with the team is often much more
important than technical prowess (provided that is adequate).

Unless that is you enjoy herding cats (something software engineering
management has been compared with - more than our fair share of divas).

--
Regards,
Martin Brown

 

[Clive Arthur]

On 13/04/2022 21:02, RichD wrote:

When you interview job candidates, you pose standard
problems, of circuits, PSpice, maybe Mathcad, etc.
Textbook stuff, you expect he knows, reviewing his resume.

Microsoft and Google are famous for posing brain twisters,
stuff \"outside the book\" (if any exists, nowadays with the net).
Do you do this? The obvious idea is to test for originality.
How much weight do you place on the responses?

--
Rich

For a fairly junior post, probably out of university...

Non-inverting op-amp circuit with feedback from 10k and 1k divider on
output with the 1k to ground. What\'s the gain? Many will say 10.

Inverting op-amp, 1k input, 10k feedback. What\'s the gain. Many will
say 10 instead of -10.

Make a two input Xor from 2 input Nand gates. Most can do it with 5,
some with 4.

Write a bit of generic code to calculate a square root.

What temperature does solder melt at? This one\'s interesting, most
don\'t know of course, but some can\'t even make a guess, and even if the
guess is wildly wrong the reasoning can be good.

And if they can, bring something along they\'ve done before.

[I remember the first proper interview I had when I was eighteen. It
was for a technical job at the BBC and there was an interview panel of
IIRC four people. They showed me a small PCB and asked me what it was.
From the 741 op-amp and the fairly large value capacitors I deduced
that it was probably a low power audio amplifier. Their notes just said
\"circuit board\". They then handed me a resistor which I told them was a
4k7 5% 1/4 watt resistor (I\'d been doing PCB assembly jobs and didn\'t
really need to think). Their notes just said \"resistor\".

Yes, completely non-technical people interviewing for a technical job.]


--
Cheers
Clive

 

[server]

On Thu, 14 Apr 2022 08:51:50 +0100, Martin Brown
<\'\'\'newspam\'\'\'@nonad.co.uk> wrote:

On 13/04/2022 21:02, RichD wrote:
When you interview job candidates, you pose standard
problems, of circuits, PSpice, maybe Mathcad, etc.
Textbook stuff, you expect he knows, reviewing his resume.

Microsoft and Google are famous for posing brain twisters,
stuff \"outside the book\" (if any exists, nowadays with the net).
Do you do this? The obvious idea is to test for originality.

Most regular interviewers have their own favourite pet questions.

Discussing the right answers online would defeat the object so they
don\'t stay useable for long in this age of everything on social media.

How many zeroes does 100! have in its decimal representation is one such
that has been popular in recent years.

How much weight do you place on the responses?

Watching how they approach an unfamiliar problem can be a sufficient
guide to do they have what it takes. Engineering can get away with an
answer that whilst not exactly right is \"good enough\" for practical
purposes.

A pure mathematics course would expect the right answer (and quickly).

You have to know what characteristics you are recruiting for to pick the
right test question(s) for the position if you are playing this game.

Whether the individual will fit in with the team is often much more
important than technical prowess (provided that is adequate).

Unless that is you enjoy herding cats (something software engineering
management has been compared with - more than our fair share of divas).

Puzzles, especially math puzzles, tell a small part about a person\'s
prospect as a design engineer. Puzzles are an easy thing for HR folks
to use.

To find out how someone will work with your design team, just do it.



--

I yam what I yam - Popeye

 

[Don Y]

On 4/14/2022 3:05 AM, Clive Arthur wrote:
> And if they can, bring something along they\'ve done before.

But, this turns the interview around and lets them control the narrative
instead of letting you drive it. Unless you have some experience with that
product or application domain, you\'re largely at their mercy (BS factor).

I\'ve also seen it backfire spectacularly on the applicant! In one
case, an engineer brought some schematics and source code that \"he\'d\"
created. As I happened to be very familiar with the product involved,
he was beyond chagrin when I asked him what part of the project
\"Bob Jackadizzledoo\" (bogus name designed to represent the oddness of
the REAL author\'s name) had done (Ans: every item that the applicant
was submitting as \"his own\").

Unfortunately, it doubly backfired on the *employer* as I told them of
this -- as well as placing some \"personal calls\" to \"Bob J\" for an
off-the-record appraisal of the applicant\'s past work (something
that HR can\'t legally do to the degree that *I* can) -- and they hired
the guy, anyway.

[He turned out to be an 18 month disaster! Only quitting when he had
to \"produce\" (literally, the day his design was due to be completed)]

 

[Clive Arthur]

On 14/04/2022 17:24, Don Y wrote:

On 4/14/2022 3:05 AM, Clive Arthur wrote:
And if they can, bring something along they\'ve done before.

But, this turns the interview around and lets them control the narrative
instead of letting you drive it.  Unless you have some experience with that
product or application domain, you\'re largely at their mercy (BS factor).

I\'ve also seen it backfire spectacularly on the applicant!  In one
case, an engineer brought some schematics and source code that \"he\'d\"
created.  As I happened to be very familiar with the product involved,
he was beyond chagrin when I asked him what part of the project
\"Bob Jackadizzledoo\" (bogus name designed to represent the oddness of
the REAL author\'s name) had done (Ans:  every item that the applicant
was submitting as \"his own\").

Unfortunately, it doubly backfired on the *employer* as I told them of
this -- as well as placing some \"personal calls\" to \"Bob J\" for an
off-the-record appraisal of the applicant\'s past work (something
that HR can\'t legally do to the degree that *I* can) -- and they hired
the guy, anyway.

[He turned out to be an 18 month disaster!  Only quitting when he had
to \"produce\" (literally, the day his design was due to be completed)]

I interviewed a guy for a technician/wireman job. He was shy, you might
say socially inept, but the things he brought along were just lovely.
Nothing that was going to change the world - for example a variable
power supply from a magazine design - but just so well put together.

He got the job. After a few weeks he came out of his shell and was very
well liked by all. He took pride in his work.

Sadly, after a few years, Parkinson\'s got him. RIP Trevor.

--
Cheers
Clive

 

[Don Y]

On 4/14/2022 3:28 PM, Clive Arthur wrote:

On 14/04/2022 17:24, Don Y wrote:

[He turned out to be an 18 month disaster! Only quitting when he had
to \"produce\" (literally, the day his design was due to be completed)]

I interviewed a guy for a technician/wireman job. He was shy, you might say
socially inept, but the things he brought along were just lovely. Nothing that
was going to change the world - for example a variable power supply from a
magazine design - but just so well put together.

I\'ve never seen an applicant bring anything (other than \"paper\") to an
interview. Many show up empty handed. Others with schematics or some
source code listings, etc.

Most of the projects/products that I\'ve designed are either too large
or too expensive to bring along for show-and-tell. Photographs, design
documents, etc. have to suffice.

When I first started on my own, I used to bring \"presentations\" (talking
papers) describing my past projects/products. I quickly learned that was
unnecessary -- if someone wanted to talk to me, they\'d largely made up
their mind to hire me (based on a referral).

So, meeting was more an opportunity to evaluate personalities, etc. (I\'ve
NOT met many of the clients I\'ve had, over the yeaars!) And, for me, an
opportunity to explore their problem to decide if it was something I\'d be
interested in taking on (I\'m always in search of a \"new\" learning experience;
no desire to rehash something I\'ve already done -- that\'s just \"a job\"! :> )

He got the job. After a few weeks he came out of his shell and was very well
liked by all. He took pride in his work.

I\'ve met all kinds. AFAICT, \"ability\" had very little correlation with other
personality factors. But, *process* was a big predicter of success.

> Sadly, after a few years, Parkinson\'s got him. RIP Trevor.

Nasty disease. A friend currently battling it. Sadly, largely in denial
(e.g., thinking if she changes her diet things will magically get better, etc.)

ALS is considerably worse. Really hard to watch and know there\'s damn near
nothing you can *do* to help/make it better.

Both suck in that they are slow marches downhill... tomorrow will be WORSE
than today... <frown>

 

[Rich S]

BITD I got asked a couple of relatively memorable ones. Interviewing at
HP Labs in Palo Alto, they asked me to derive the Fresnel formulae for
reflection of a plane wave at a dielectric interface.

As to being the interviewee, mine cannot compare to that! ;-)

The one \"extreme\" experience; I was handed a multipage
exam, was like taking my college ACTs all over again.
It took two hours to complete, involved all kinds of math, physics,
, written challenges. And picking specs out of their databooks.
They called it the \"Howard Hughes Test\"
I never did figure out why, Did HH grill his candidates that way?

I must of done OK.. they hired me.
-=RS

 

[RichD]

On April 14, Clive Arthur wrote:

When you interview job candidates, you pose standard
problems, of circuits, PSpice, maybe Mathcad, etc.
Textbook stuff, you expect he knows,
Microsoft and Google are famous for posing brain twisters,
stuff \"outside the book\" (if any exists, nowadays with the net).
Do you do this? The obvious idea is to test for originality.
How much weight do you place on the responses?

Write a bit of generic code to calculate a square root.

That\'s what I have in mind.

Probably the applicant has never done this, now he\'s on his own,
he has to think his way through a problem. That\'s what you
watch - not the answer, but his thinking.

What temperature does solder melt at? This one\'s interesting, most
don\'t know of course, but some can\'t even make a guess, and even if the
guess is wildly wrong the reasoning can be good.

OK, I\'ll bite - how does one \'reason\' one\'s way to a melting point?
Mentally solve Schrodinger\'s equation, given the molecular structure of solder?

They showed me a small PCB and asked me what it was.
From the 741 op-amp and the fairly large value capacitors I deduced
that it was probably a low power audio amplifier. Their notes just said
\"circuit board\".
They then handed me a resistor which I told them was a
4k7 5% 1/4 watt resistor. Their notes just said \"resistor\".

hmmm... did any candidate fail this exam?

--
Rich