interviewing

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

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.

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

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.

> 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.

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!

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.

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.

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

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