Electronics-Related.com
Forums

interviewing

Started by RichD April 13, 2022
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.&nbsp; 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.&nbsp; Especially if they don't because of an artificial time > constraint.&nbsp; 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