That is funny story, that is much better than my ++ operator.
write the intersectrect function. Just to see if they can work through
problem. The function is about 9 lines, 1 "return true;", 4 of which are
see how they would tackle a problem and work through it.
AliR.
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
See below...
On Thu, 19 Mar 2009 13:38:32 -0500, "AliR \(VC++ MVP\)"
<AliR@online.nospam> wrote:
That is the point, it doesn't really have a real world application.
Actually
what might be real world programming practices to you might not be to
me,
or
my past experience (18 years of VC++ programming). for example an
interview
I went to asked me which is faster pre-increment, or post-increment, at
the
time I didn't know the answer, because I was never concerned with that,
and
never really had to override a ++ operator, but that doesn't mean that I
don't know how to override an operator, but to be honest 75% of the time
I'll have to lookup the method signature from the help.
Anyway, the string reversing is a good example of finding out how the
applicant thinks, and approaches problems that he might not have seen
before, I would want someone who can solve new problems rather than
apply
old techniques to new problems. One of my favorites is a function that
tells if two rectangles intersect or not. Easy question, but alot of
people
get hung-up on it and never even ask a question, even after I tell them
that
they can ask questions.
****
CRect a(...);
CRect b(...);
CRect c;
if(c.IntersectRect(&a, &b)) ...
Not terribly difficult. About as hard as strrev to reverse two strings.
I once
challenged someone during an interview, when he asked me about the
string
reversal; I told
him sttrev and he told me that strrev was not an acceptable answer. My
reply was along
the lines of
"That is a toy problem for a toy program for beginning programmers. A
professional calls
strrev because it makes no sense to waste the employer's time and money
re-inventing a
solution that already exists". I got the job.
On the other hand, I was once handed over to "our MFC expert" so he
could
evaluate me. He
asked a bunch of rather simple questions, then he asked the question,
"What's the fastest
way to allocate memory", so I said "malloc or new. malloc in C, new in
C++". So he
looked at me and said, "No, seriously, what's the fastest way to
allocate
memory?" I
said, "I just told you: malloc or new. There isn't a faster way." He
said "Sure there
is", so I said, "No, there isn't. That's it." In frustration, he said
"Of course there
is: VirtualAlloc!" To which I replied "No, that's not true." He became
more and more
insistent that he was right, and I told him that the only correct answer
was the one I had
given him. I finally said, "Well, you are flat-out wrong, that
statement
is nonsense.
I've even written a book with a chapter on how to write a storage
allocator, and I think I
know more than a little bit about it. I've written several in my life.
Your assertion is
simply wrong, and I'm sorry you believe something so erroneous" Very
shortly the manager
came back and took me away. "How did it go?" he asked. "Well, he asked
about six trivial
questions, then made a complete fool of himself by telling me that
VirtualAlloc is the
fastest way to allocate memory. If he's your best programmer, you're in
trouble." I
didn't get the job, but I did have the satisfaction of proving, by doing
actual
performance measurement, that VirtualAlloc *is* slower than malloc or
new.
Not by much,
mind you, only about three orders of magnitude. I sent the results and
the program that
produced them to the manager.
In retrospect, I realized he was probably an ex-Unix programmer who
still
believed that
memory allocation was expensive (the Unix allocator sucked for so many
years that all Unix
programmers who learned programming up until the mid-1990s tend to still
think storage
allocation is outrageously expensive. Which was true in Unix because the
allocator was so
badly written).
joe
****
AliR.
"Colin Peters" <cpeters@coldmail.com> wrote in message
news:49c28334$1_5@news.bluewin.ch...
Brian Muth wrote:
I agree more with Tom.
I really don't think your test is very effective. I'd throw it out.
Imagine you are interested in interviewing for a chemist. You could
ask
"What is the atomic weight of Zirconium?" Yes, if they just walked
out
of
the lab, they might happen to know the answer. But they may still be
an
excellent chemist if they don't know. If you pass on candidates who
don't
answer your test questions, you probably are passing over some
excellent
programmers.
We have a short quiz in our interviews as well. But it's very
generic.
Questions are like this:
"Choosing any programming language, show me how you would reverse all
the
characters in a string"
But what's the real world application of that? I know it's a Joel on
Software favourite, but when do you need to do this, or anything
similar?
"Discuss the various ways you could share a variable between two
running
processes".
That's a keeper. And would probably lead to a meaningful discussion.
I'm interested in how a candidate approaches a problem. Stuff like
CStringArray and DDX can be taught to a smart employee.
Brian
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm