I have to interview a C++ programmer tomorrow. What are a couple ofyour favorite questions I can use

[werasm]

[Please do not mail me a copy of your followup]

jaialai technology <[email protected]> spake the secret code

I have to interview a C++ programmer tomorrow.
What are a couple of your favorite questions I can use?

Walk them over to your developer area and pair program with them for
an hour or two.  Have the applicant "drive" while you "navigate".  If
they are a good programmer, it will become obvious after about 20
minutes.  If they can "talk the talk" but can't "walk the walk" that
will also become obvious after about 20 minutes.  It also identifies
people who program well but interview poorly and people who interview
well but program poorly.  After about half an hour of doing real code
in front of someone, its difficult to keep up an "act" in hopes of
getting the job.  The rest of the time in the hour or two you spend
getting to know them a little bit and find out if they are someone you
could actually stand to have on your team (personality wise).

Thankfully I was not interviewed this way - else I would have never
got the job...

My best ideas I get when I'm on my own - usually when I'm on the
toilet, which is where I go when I'm out of ideas and want to get away
from the noise. I have contemplated that my though process is somehow
stimulated by the lesser act of ... By the time I'm pair programming,
I already have my ideas - which I usually get when not programming at
all.

Regards,

W

 

[James Kanze]

Hm, this made me curious for what
-1 < 60000
would mean wher int and long is 16 bits... Would that make
60000 unsigned?

The '98 standard, 2.13.1p2:
"The type of an integer literal depends on its form, value,
and suffix. If it is decimal and has no suffix, it has the
first of these types in which its value can be represented:
int, long int; if the value cannot be represented as a long
int, the behavior is undefined."

Looks it is UB, and the compilers you mentioned didn't get it
wrong standard-wise, only QoI-wise.

For 60000, no, because it is guaranteed to fit into a long int.
But you're right---the standard makes it undefined if the
constant doesn't fit into a long int, so the compilers are
conform, and can do anything they like with it. (I suspect that
this is there because the earliest compilers did treat it as an
unsigned long, and the committee didn't dare break them,
although it knew that the only correct solution was to preserve
signedness.)

Honestly I see little excuse from making it ill-formed. (Guess
there is a ton of code around that use such literals without u
suffix to init an unsigned type, and they left a chance to
keep it work...)

Well, comparisons such as Stefan's would be a reason. But
fundamentally, I could live with it being defined to unsigned
long (except that adding long long would silently change the
behavior---but that's the case for so many things already that
one more won't hurt). But it really does have to be defined:
it's either an error or it has some defined meaning---it
shouldn't be undefined behavior.

 

[James Kanze]

"James Kanze" <[email protected]>

[...]

I don't get this -- what looking over the shoulder? The guy
would do the review, and I play the part of defender.

I was referring back to the original suggestion, using pair
programming. But to a certain degree, the criticism holds for
a lot of things: you can't expect someone to come in and feel
comfortable in a situation he's never experienced in 20 minutes
or so. And if he's not comfortable, you'll not really get a
good feeling for what he can do once he's adapted to whatever
process you use.

 

[James Kanze]

On Dec 2, 2:25 am, (e-mail address removed) (Richard)
wrote:

[...]

Thankfully I was not interviewed this way - else I would have
never got the job...

My best ideas I get when I'm on my own - usually when I'm on
the toilet, which is where I go when I'm out of ideas and want
to get away from the noise. I have contemplated that my though
process is somehow stimulated by the lesser act of ... By the
time I'm pair programming, I already have my ideas - which I
usually get when not programming at all.

That pretty much corresponds to me as well: my best ideas come
when I'm in the shower or driving. Another thing which seems to
occur (and not just with me): I'll realize where the error was
five minutes after I've left the office.

 

[Stefan Ram]

Stefan, how would you react if the guy at the interview
pointed out your answer is wrong?

This could not happen, because the person being interviewed
would only know my /question/ - not my /answer/.

If his answer is not what I expect and not obviously wrong,
I would write down his answer and thank him for his answer.

I would not immediately judge his answer. Well, at least I
hope so. At the end of the interview, I would thank him
again and tell him that I will get back to him within the
next days.

If he would ask for a judgement, I would answer that I am
not sure yet and need some time.

After the phone interview has been terminated, I would
start to investigate this question again, before I would
then use any newly gained insight to assess his answer.

The question whether this is unspecified or undefined
behavior seems somewhat tricky here to me, because it is
undefined in the case of »60000« only under some
implementations. So, whether it is undefined behavior is
implementation specified. This brings up the question
whether an implementation specified behavior where some
implementations might choose to specify »undefined behavior«
is unspecified or undefined altogether. I deem to to be
unspecified, because at the uppermost level it is unspecified.

(For example, when you have the free choice whether you
want do what you like or be forced to run, does this mean
altogether that you have a choice or are being forced?
I deem it to mean that you have a choice, because only if you
choose so, will you be forced. And here, does it mean that
the implementation specifies the behavior or is it
undefined behavior? I say the implementation specifies
the behavior, because it will only be undefined if the
implementation has chosen so [by using 16-bit longs]).

Thanks for the quotation from the '98 standard, 2.13.1p2,
which I was not aware of yet!

 

[Richard]

[Please do not mail me a copy of your followup]

James Kanze <[email protected]> spake the secret code

Pair program what?

You could work on an exercise, but I prefer to have them work on a
piece of production code.

Having the candidate walk through the

development of something with you is obviously a good idea, but
it has to be something small enough and concrete enough for them
to reasonably be able to make some progress in the alloted time.

If they can't make any progress in 2 hours with you navigating, then
IMO either your code is absolutely crap to begin with or the person
you're interviewing isn't any good.

You could also set the interview up as a code review session.

Reviewing code is not writing code. It tells you less about the
applicant than working with them IMO.

that a person "acts" rather than really performs is part of his
personality. In practice, though, I've found a few simple
questions sufficient to weed out the bluffers. At least in my
experience, people who know how to write CV's which are mostly
fiction don't know anything about programming, and even simple
questions like "why would you declare a destructor virtual?"
will leave them struggling---or answering who knows what
nonsense. And once you know that the CV isn't bluff, if it
fits, what's left is the personality issues.

Yes, those people are easily weeded out so you don't waste time pair
programming with them. However, I've seen plenty of people who can
answer those questions that still write shitty code. If you pair
programmed with them for an hour, it would be obvious they write
shitty code.

 

[Balog Pal]

Well, comparisons such as Stefan's would be a reason. But
fundamentally, I could live with it being defined to unsigned
long (except that adding long long would silently change the
behavior

Uh, allowing unsigned would be an awful idea -- that was the possibility to
make me fetch the standard -- as combined with the integral promotion rules
the above expression's value would be strict false. (promotions suck with <

> comparisions -- fortunately the compilers I use have a consistent warning

that I elevated to error. )

But it really does have to be defined:
it's either an error or it has some defined meaning---it
shouldn't be undefined behavior.

Yeah.

 

[Balog Pal]

The question whether this is unspecified or undefined
behavior seems somewhat tricky here to me, because it is
undefined in the case of »60000« only under some
implementations. So, whether it is undefined behavior is
implementation specified. This brings up the question
whether an implementation specified behavior where some
implementations might choose to specify »undefined behavior«
is unspecified or undefined altogether. I deem to to be
unspecified, because at the uppermost level it is unspecified.

IIRC the standard terms go as:

- "implementation specified" means the compiler must state the
value/behavior in the dox and do that. (i.e. actual values in limits.h,
signedness of char, ...)
- "unspecified" means the description allows multiple fixed outcomes, one of
them must happen, the implementation may pick a different one for other
ocasions, and has no obligation to tell which option is chosen.
- "undefined" means anything can happen.

The implementation is allowed to specify anything of the open stuff, if it
does, then that is binding.

Unspecified is not the uppermost level, as that restricts behavior while UB
doesn't.

The problem at case (with values over 2G, the 16-bit long-using platform I
imagined turns out not conforming) is either true or UB -- depending on the
impl-specified value of LONG_MAX.

I say the implementation specifies
the behavior, because it will only be undefined if the
implementation has chosen so [by using 16-bit longs]).

No. The standard specifies the behavior for "fitting" cases, otherwise we
can't say it is specified -- unless the implementation actually took the
pain to specify this area of UB (not very likely).

 

[Noah Roberts]

I have to interview a C++ programmer tomorrow.
What are a couple of your favorite questions I can use?
This is for a beginner. Sadly, the job is in India and I will be
interviewing this guy
over the phone from the US.

Sorry to be blunt, but I'd just tell the asstard that created the
situation to go stick it where the sun doesn't shine. If you look
closely at your boss you'll probably notice that he has two layers of
skin on his face because anyone that would say, "Hey, lets hire
beginners on the other side of the planet and manage them here," has
their head so far up their ass that it's popped back out the other side.

 

[James Kanze]

"James Kanze" <[email protected]>

Uh, allowing unsigned would be an awful idea

Yes and no. The way C++ handles signed/unsigned comparison is
awful, and the fact that the type depends on the value isn't
anything to be proud of either, but given the way those aspects
are defined... It's not very logical either that 0xB2D05E00
behave differently than 3000000000.

If we were defining a new language from scratch, we might give
unsigned the semantics of a cardinal (with e.g. the subtraction
of two unsigned resulting in an int), not allow implicit
conversions, and say that 3000000000 and 0xB2D05E00 are either
int or a compiler error---if you want long long, you'd have to
write 3000000000LL, and if you want unsigned, you'd need the U
postfix. But that language wouldn't be C++, and it wouldn't
have much to do with the C/C++ family of languages---we might as
well replace {...} with BEGIN...END while we're at it.

-- that was the possibility to make me fetch the standard --
as combined with the integral promotion rules the above
expression's value would be strict false. (promotions suck
with < > comparisions -- fortunately the compilers I use have
a consistent warning that I elevated to error. )

Yeah.

Note that the "defined meaning" would still be "implementation
defined": on a Unisys mainframe (36 or 48 bit int's), for
example, it will be different from on the typical 32 bit
machines, where 3000000000 isn't representable in a signed
integral type. And of course, now that we've got long long, the
problem won't occur until something like 10000000000000000000.

 

[James Kanze]

[...]

The question whether this is unspecified or undefined
behavior seems somewhat tricky here to me, because it is
undefined in the case of »60000« only under some
implementations.

"60000" is never undefined. The type is implementation defined,
and may be either int or long (but nothing else), and the value
must be 60000, with no exceptions.

So, whether it is undefined behavior is
implementation specified. This brings up the question
whether an implementation specified behavior where some
implementations might choose to specify »undefined behavior«
is unspecified or undefined altogether. I deem to to be
unspecified, because at the uppermost level it is
unspecified.

There's nothing "unspecified" here in the standard sense. The
size and representation of a long are "implementation defined"
(i.e. the implementation must specify them in its documentation,
and the standard imposes some limits on what is allowed). What
happens with something like "3000000000" is either exactly
defined or undefined behavior, depending on the implementation
defined value "LONG_MAX". It's conditional undefined
behavior. (And of course, any implementation is free to
define it however it wants. From a QoI point of view, I'd like
to see it defined as a compile time error; for reasons of
backwards compatibility, it's often defined as resulting in an
unsigned long.)