interviewing

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.

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.

+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 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!

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.

Yes.

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.

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>?"

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!]

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

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.

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.

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.

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

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?)

Yes ! Attitude and passion counts a LOT !

boB

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.

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

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

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.

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.

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"! :> )

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

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>

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

int i=1,root=0; while (input > 0) { input -= i; i += 2; root++; }

Well, you didn't say it had to be FAST...

-- john, KE5FX