interviewing

On Thursday, April 14, 2022 at 3:05:59 AM UTC-7, Clive Arthur wrote:
> Write a bit of generic code to calculate a square root. 

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

On 4/14/2022 7:10 PM, RichD wrote:

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

The typical sort of "test" for "programmers" would be a sort.
As this is a well-baked issue, the test is geared at noting
if the applicant knows the different types of sort algorithms
and the tradeoffs/execution times of each.

The "red flag" being the applicant who doesn't look for more
clarification on the number of items being sorted, their
characteristics, the nature of the list *before* the sort,
how it will be used *after* the sort, etc.

Because it is a relatively *simple* problem, you don't have to
worry about "test averse" applicants "choking" in the process.

Of course, if you are looking for "niche" applications, one
might ask the applicant to describe scenarios where deadlock
can occur, livelock, priority inversion, etc.  Or, issues
regarding specific protocol stacks, etc.

And, if the programmer will have to interface to hardware,
there are a variety of simple challenges that will tell you
if he knows the issues that are pertinent, there (and how
reality can defy his code's assumptions -- in delightfully
clever ways!)

But, "process" is always paramount.  Is he a defensive coder, etc.?

On Thu, 14 Apr 2022 19:10:26 -0700 (PDT), RichD
<r_delaney2001@yahoo.com> wrote:

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

For an integer, just binary search the bits, like an SAR ADC.

-- 

If a man will begin with certainties, he shall end with doubts, 
but if he will be content to begin with doubts he shall end in certainties.
Francis Bacon

On Thu, 14 Apr 2022 19:10:26 -0700 (PDT), RichD
<r_delaney2001@yahoo.com> wrote:

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

What I usually do is to give the candidate a sheet of paper and ask
him to draw a block diagram and describe their favorite project in
great detail.  This generally flushes the poseurs out - the know none
of the expected details.

There was one time when I was screening June grads in EE, and asked
this kind of question, and got nowhere.  Long story short, I
eventually asked him to state and explain Ohm's Law.  Total blank.  

It developed that he was on the Varsity Football Team.  Hmm.  Probably
never attended a single class.  I do not know whose idea it was to
grant an EE degree, because there is no way he could ever fake it in
an EE job.

Joe Gwinn

I was interviewed for the job of well logging engineer. Besides answering common engineering questions, I was asked to solve the problems written on a whiteboard behind my back. The usual stuff, like "what is the next number in this sequence".
Anyway, I got the job.

Wim Ton 

On 16/4/22 3:06 am, John Larkin wrote:
> On Thu, 14 Apr 2022 19:10:26 -0700 (PDT), RichD
> <r_delaney2001@yahoo.com> wrote:
> 
>> 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.
> 
> For an integer, just binary search the bits, like an SAR ADC.

Quicker to start by finding the highest 1 (number of significant bits). 
This is a single opcode in many architectures. The square root will have 
half as many significant bits, or one fewer than that. Instantly narrows 
the search space by a *lot*.

CH

On 14/04/2022 15:35, jlarkin@highlandsniptechnology.com wrote:
> 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.

The open ended puzzle tests are not particularly useful when used by HR. 
Anyway they prefer multiple choice off the shelf standardised 
personality tests - so much easier to mark.

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

Although I draw the line at the nasty modern practice of tasking some 
bunch of poor unfortunate would be recruits with solving one of your 
tricky real world problems for nothing in an attempt to win the job.

You can generally tell pretty quickly whether or not someone really 
knows their stuff as claimed on the CV or has mugged it up from "Ace the 
technical interview for Dummies" or even done no prep at all.

"What would you like to ask me about the job?" can be informative too.

We had a couple of short test pieces of code ~20 lines for each language 
and the test was to explain what the code does. Much like you would with 
a circuit diagram in hardware. Quite a few had no real understanding of 
the language(s) that they claimed to know fluently. Saved a lot of time.

One of the key requirements is to have a balanced team.

You need the odd completer finisher to ensure that the last remaining 
uninteresting bits do get done when the people who break new ground are 
off doing the next interesting big project. Resource is always finite.

-- 
Regards,
Martin Brown

On Sat, 16 Apr 2022 11:37:50 +0100, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:

>On 14/04/2022 15:35, jlarkin@highlandsniptechnology.com wrote:
>> 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.
>
>The open ended puzzle tests are not particularly useful when used by HR. 
>Anyway they prefer multiple choice off the shelf standardised 
>personality tests - so much easier to mark.
>
>> To find out how someone will work with your design team, just do it.
>
>Although I draw the line at the nasty modern practice of tasking some 
>bunch of poor unfortunate would be recruits with solving one of your 
>tricky real world problems for nothing in an attempt to win the job.
>
>You can generally tell pretty quickly whether or not someone really 
>knows their stuff as claimed on the CV or has mugged it up from "Ace the 
>technical interview for Dummies" or even done no prep at all.
>
>"What would you like to ask me about the job?" can be informative too.
>
>We had a couple of short test pieces of code ~20 lines for each language 
>and the test was to explain what the code does. Much like you would with 
>a circuit diagram in hardware. Quite a few had no real understanding of 
>the language(s) that they claimed to know fluently. Saved a lot of time.
>
>One of the key requirements is to have a balanced team.
>
>You need the odd completer finisher to ensure that the last remaining 
>uninteresting bits do get done when the people who break new ground are 
>off doing the next interesting big project. Resource is always finite.

We did a job interview yesterday. The guy arrived at 11 AM and left
just after 6 PM. I walked him over the I80 footbridge back to his car.

We brainstormed the architecture and details of a planned product
line, including things that we haven't yet resolved. Free consulting.

I taught him a few things about pcb traces and grounding in picosecond
circuits. He hadn't done any fast wideband stuff and had some
conventionally silly ideas about return currents, but he is sound on
grounding. Looks good at thermals and packaging too.

It was interesting to see not just his intelligence and technical
range, but how he generated ideas and reacted to other peoples' ideas.
Perhaps a tad dogmatic, but I guess people are stressed in interviews.

He also cooks, and bakes bread, so we took him for Thai lunch outdoors
and then walked to Tartine and bought him a gigantic sourdough country
loaf. All that sort of stuff suggests how people might work together.

He admits to being autistic, which is if anything an asset in our
business. Another guy that we zoom interviewed this week is autistic
too. Visibly so.

We agreed that if we hire him, it will be as a virtual intern, in
other words we'd try it for few months to see how it works and part
friends if not. That was his suggestion, and I like it.



-- 

I yam what I yam - Popeye

On April 15,  wim...@gmail.com wrote:
> I was interviewed for the job of well logging engineer. Besides answering 
> common engineering questions, I was asked to solve the problems written 
> on a whiteboard behind my back. The usual stuff, like "what is the next 
> number in this sequence". 

77, 49, 36, 18, ... ?


--
Rich

RichD wrote:
> On April 15,  wim...@gmail.com wrote:
>> I was interviewed for the job of well logging engineer. Besides answering
>> common engineering questions, I was asked to solve the problems written
>> on a whiteboard behind my back. The usual stuff, like "what is the next
>> number in this sequence".
> 
> 77, 49, 36, 18, ... ?
> 
> 
> --
> Rich
> 
8, 0, 0, 0, 0,....

Cheers

Phil Hobbs