Subj : Re: Reverse words in a string (Another Interview question)
To   : comp.programming
From : Scott Moore
Date : Thu Sep 29 2005 12:58 pm

Jaspreet wrote On 09/29/05 09:36,:
> Hi All
> 
> Just had another interview with those same questions which hardly make
> a sense except this one probably.
> 
> I was asked to reverse the words in a string. Say if we have "Welcome
> to google groups", I need to have it reversed to "groups google to
> Welcome".
> 
> I told the interviewer that we could keep each word in a node in a
> linked list and then try to reverse the linked list. That is:
> 
> --Original linked list
> Welcome -> to -> google -> groups
> --After reversing
> groups -> google -> to -> Welcome
> 
> I guess the interviewer had learned/used something else. He wanted me to
> try reversing it inline that is without the option of using another
> linked list. He probably wanted me to do something similar to - First
> reverse the whole string and then individually reverse the words
> 
> a) Reverse the string to get:
> spuorg elgoog ot emocleW
> 
> b) then reverse the individual words to get:
> groups google to Welcome.
> 
> Now agreed my solution would take up extra memory but am not sure which
> one is a faster and more efficient solution. I did the mistake of
> telling the interviewer that the solution he thinks of is slightly
> slower and in-efficient to code or go through by future programmers
> which I am sure he did not like.
> 
> I would like an opinion on this from you. Which one is a better and a
> more efficient solution ?
> 
> Please let me know. I guess thats fine with you.
> 
> Apologies for such a long post.
> 

Welcome to what I call "lock in". I have had the experience as well,
that some interviewers not only ask you to solve a given problem, but
solve it exactly the way they expect it to be solved. Even if you solve
the problem, he/she might still consider you to be "difficient" even
if you successfully solved the problem.

It does not even matter if you solved it MORE efficiently than they did.
I had some interviews like that where I had to explain my solution to
the interviewer, who finally had to admit that I had solved the problem,
but had him become visibly agitated during the process. It was clear
that he didn't appreciate my independent nature in all this.

When I do interview questions, I let them solve it any way they can.
I don't always understand their solution, so I ask them to explain it
to me. Just the process of their explaining it to me often shows me
more about their programming skills than the problem itself.

Two classic interview stories of mine:

One was a company that gave me a simple C problem about what result would
be returned from a function. I replied that the program was not valid C.
It wasn't, the guy was relying in an uninitialized local variable, which
is a no-no in standard C. He was relying on his on particular implementation
of C. The interview went rapidly south as you might imagine. I won't lie
to get a job.

Second was an assembly language job where the guy asked me to describe
accessing a table in a small microprocessor's assembly language. I
wrote a solution on the board, and he smiled at me much as you would to
a small child, then proceed to tell me how with "advanced thinking" you
could locate the table on a page boundary so that the lower bits were
zero, and simplify the code by relying on the lower address bits being
zero. It's a common assembly language technique.

I told him that I knew that quite well, but I don't program using such
dependent tricks. They usually aren't worth the headache of having to
always keep that table specially aligned, in trade for an instruction or
so saved.

By the time I left there, he was visibly angry. I didn't mind. I don't
want a boss like that in any case.

.