Author Topic: C++ interview questions that do not suck  (Read 26078 times)

0 Members and 1 Guest are viewing this topic.

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 1947
  • Country: nl
C++ interview questions that do not suck
« on: May 06, 2014, 05:54:42 pm »
See subject.

I've been checking out several lists with "typical interview questions" and generally they put me in a state somewhere between giggling like a little girl and perpetual eye-rolling.

Sooo, any and all lists with actually relevant questions you can think are much appreciated! :)
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: C++ interview questions that do not suck
« Reply #1 on: May 06, 2014, 06:19:12 pm »
Q1. "Write a linked-list class template. Here's some paper and a pen."
Q2. "Write a predicate function that says whether two time segments overlap. Here's some more paper."
Q3. "How can you prove that your code actually works?"

Only Q1 is C++ specific.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 1947
  • Country: nl
Re: C++ interview questions that do not suck
« Reply #2 on: May 06, 2014, 07:55:05 pm »
A1: singly, doubly, or curiously linked?
A2: In what way are those time segments defined? Given a discretized bit-array where each bit represents a time slice I can make do with a bit-reduce and operator. :P Or if each time segment is denoted by T_start and T_stop, then I think I can manage to return a boolean based on some < not and.
A3: First actual brain teaser, being a bit of a math pedant. To which the proper answer probably is: "Are you management? if yes, jump out of window now, because the answer is the unsatisfactory YOU CANNOT for all non-trivial problems solved in an economically viable way." The best you can do is arrange for decent test coverage to reduce the change of error to an acceptable level, whatever that level may be. Hell, you should already be so happy if you can mathematically prove the algo you designed is correct. Let alone the implementation on irradiated actual hardware.

And speaking of which, how do you typically estimate what decent test coverage is in the embedded area? And how does one do unit testing? It's come up before in other threads, but never really read an in depth answer. What I can think of is to do standard boring unit tests against stubs at every stage during development. And testing on actual hardware as well at a later stage (aka not every stage, because this form of testing is more time consuming == expensive).

Right now I do a bit of a mix of that, but that's only for my own fun projects. So I was wondering how that's done Out There [tm].

Edit: And shame on me. Of course thanks for your reply. :) Guess reading all the drivel on the interwebs makes the pedantic bit go into overdrive. :P
« Last Edit: May 06, 2014, 07:59:38 pm by mrflibble »
 

Offline madshaman

  • Frequent Contributor
  • **
  • Posts: 699
  • Country: ca
  • ego trans insani
Re: C++ interview questions that do not suck
« Reply #3 on: May 06, 2014, 08:00:41 pm »
One of mine: write an implementation of Tetris, any platform you want.  I'll want to see the source.
To be responsible, but never to let fear stop the imagination.
 

Offline madshaman

  • Frequent Contributor
  • **
  • Posts: 699
  • Country: ca
  • ego trans insani
Re: C++ interview questions that do not suck
« Reply #4 on: May 06, 2014, 08:15:43 pm »
More: what's an ABI?  what's a calling convention?  Why might it be important to know these things?

Can the numerical value of a pointer change after an assignment?

P1 == P2 but ((void *) P1) != (void *) P2)

If so, why?

You're debugging some code, and you notice that an array of yours gets partially trashed after stepping through some trivial code that shouldn't or can't effect that array.

What might be happening?  Describe how you'd
continue to isolate the problem.

You have a robust library which targets the correct processor, has no dependencies beyond the C standard library but was produced for a different OS, uses a different ABI, and has a different object file format than the target platform.

You only have the binary for the library but it's archive and object file format are well known.

How would you create a native library with the same entry points from this binary?



To be responsible, but never to let fear stop the imagination.
 

Offline Neilm

  • Super Contributor
  • ***
  • Posts: 1434
  • Country: gb
Re: C++ interview questions that do not suck
« Reply #5 on: May 06, 2014, 08:19:59 pm »

A3: First actual brain teaser, being a bit of a math pedant. To which the proper answer probably is: "Are you management? if yes, jump out of window now, because the answer is the unsatisfactory YOU CANNOT for all non-trivial problems solved in an economically viable way." The best you can do is arrange for decent test coverage to reduce the change of error to an acceptable level, whatever that level may be. Hell, you should already be so happy if you can mathematically prove the algo you designed is correct. Let alone the implementation on irradiated actual hardware.


About 10 years ago I was talking with a guy who knew about the embedded code in tank fire control systems. He told me that even to correct the spelling mistake in a string on the display would required over £1.5m of testing.
Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe. - Albert Einstein
Tesla referral code https://ts.la/neil53539
 

Online AG6QR

  • Frequent Contributor
  • **
  • Posts: 810
  • Country: us
    • AG6QR Blog
Re: C++ interview questions that do not suck
« Reply #6 on: May 06, 2014, 08:30:36 pm »
This is not in an EE context, nor in an embedded systems context, but I've worked on software for CAD/CAM and analytic geometry.  I've presented this question to interview candidates:

Write a function to plot a circular arc on an x-y plane using a sequence of straight lines.  Assume the graphics system gives you two functions, moveto(x,y) and drawto(x,y), where moveto positions the cursor to a spot, and drawto draws a straight line from the current position to the place you specify.

Your function will accept the x,y coordinates of the arc's center point, the radius, a start angle in radians, an end angle in radians, and a tolerance, defined as the maximum distance your straight lines are allowed to deviate from the actual ideal circle.  All the numbers are of type float.

I ask the candidate to write the function out on a whiteboard, explaining what they were doing.  It's OK to ask for clarifications on the problem statement as needed.  I don't worry much about minor syntax errors.


In my experience, this question very clearly separated out candidates into two distinct groups.  Those who thought it was so trivial that they had trouble understanding why I was wasting their time on such a kindergarten exercise, and those who didn't have a clue where to begin, and even with some coaching on where to begin, couldn't figure out the middle or end of the solution.  Most candidates fell into the latter group, unfortunately.

Of course, this question isn't C++ centric; it could be done in any language.  It's mostly about understanding of algorithms and basic geometry, but it's also about ability to interact and explain yourself on the fly.  And since the candidates were applying for jobs involving writing code to implement geometric algorithms, this question was very fair game.

But for a different employer, where the job involved implementing code for different types of applications, I'd expect very different questions.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: C++ interview questions that do not suck
« Reply #7 on: May 07, 2014, 12:56:19 am »
See subject.

I've been checking out several lists with "typical interview questions" and generally they put me in a state somewhere between giggling like a little girl and perpetual eye-rolling.

Sooo, any and all lists with actually relevant questions you can think are much appreciated! :)

How about these assessment questions before they even granted you an interview?

Quote
Question 1
Write a function that supplies a color masking operation on two colors (Source and CMask) supplied as 32-bit unsigned integers.  8-bit red, green, and blue components are packed into these integers. 
For each color component, perform the following operation:
 If the CMask component is non-zero, the output  is CMask.  Otherwise, the output is Source.
#define R_MASK 0x00FF0000
#define G_MASK 0x0000FF00
#define B_MASK 0x000000FF

Question 2
Write a function that tests if a point is within a specified distance (dist) of any part of a filled 2D rectangle.  The rectangle is specified by bottom left corner, a width, and a height.

Question 3
Write a function to swap two adjacent elements (elem and elem->next) in a singly-linked list. Assume that you do not have access to the data component of the elements (and thus cannot just swap the data).
This is tricky since the pointer has to be passed by reference, there is no guarantee the invoking method will pass the actual pointer element.

Question 4
Describe a system for representing the following types of entities that may occur in an MMO.  All are visually represented in the world, and may have to be sent to the client:
* NPC – Needs to run AI, may be involved in combat, needs to walk and collide with objects
* Player – Connects to the client, may be involved in combat, needs to walk and collide with objects
* Crowd NPC – Fills up a city, runs limited AI, not involved in combat, does not collide with objects
* Door – Has an open and shut state, may be destroyed by combat, may obstruct other entities
The server has limited memory; design a system with as little waste as possible.  Please compose your response in the form of a graph or code that depicts a set of classes with stub functions inside.

Question 5
Write a function that will be used to help compose a resistance circuit.  The function takes a list of resistors with resistance values in Ohms specified for each.  It also takes a target resistance in Ohms and returns whether that resistance can be composed using the input resistors.  Resistors are only attached in simple parallel and series relationships.  Not every resistor needs to be used.
Consider that two resistors may be attached in series or in parallel.  If attached in series, the resulting resistance is the sum of the two component resistors: (R1 + R2).  If attached in parallel, the resulting resistance is given by Inv(Inv(R1) + Inv(R2)) where Inv(X) is 1 divided by X.
You may consider doing the following: removing two resistors from your list of remaining resistors, attaching them either in parallel or series, and adding a ‘pseudo’ resistor back to the set with the value of (R1 + R2) or Inv(Inv(R1) + Inv(R2)).  This ‘pseudo’ resistor can then be composed with any other resistor in the set using the series or parallel rules.
Note that there is no need to special case a set of three or more resistors.  The resistance of three resistors is the same as the resistance of the ‘pseudo’ resistor formed from the first two added to the third in both the series and parallel case.
No knowledge of electrical engineering is required to answer this question. All necessary information is included in the above description.

I got the interview but they scheduled me too late so I ended up taking another job elsewhere that interviewed me earlier and was for a better position anyways.

Glad I did, since now we are interviewing people that were in that company because they closed down.

Edit: This was 5 years ago btw, now they probably will ask you about lambda expressions and all kinds of C++11 related things as well.

« Last Edit: May 07, 2014, 01:52:10 am by miguelvp »
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: C++ interview questions that do not suck
« Reply #8 on: May 07, 2014, 02:07:03 am »
A1: singly, doubly, or curiously linked?
A2: In what way are those time segments defined?

etc.
Yes, exactly.

Part of the interview is to see how the candidate deals with incomplete specifications. Can s/he recognize when more information is needed, or will s/he zero in on one interpretation that seems to be the most obvious and blame the user later on when it turns out the simplifying assumptions were wrong.

Back when I was doing technical hiring, it was really useful to give the same question (Q2) to every candidate programmer over a number of years. The time span overlap is a pretty simple idea that any competent engineer *should* be able to implement in 20 minutes. Plus, it seems easier than it actually is, so even folks who get nervous in interview situations jump right in without second guessing themselves too much. As I remember, there were 4 or 5 distinct solutions that actually worked, and after the first few minutes, I could usually tell if the candidate was going to come up with a solution.
 

Offline Stonent

  • Super Contributor
  • ***
  • Posts: 3824
  • Country: us
Re: C++ interview questions that do not suck
« Reply #9 on: May 07, 2014, 06:15:51 am »
Q: Why did they call it C++ ?

You never know, they may get it wrong!
The larger the government, the smaller the citizen.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: C++ interview questions that do not suck
« Reply #10 on: May 07, 2014, 06:40:47 am »
Q: Why did they call it C++ ?

You never know, they may get it wrong!

Not that it will matter on a hire.

My understanding is because of BCPL. C derived from B, C++ derived from C, so it could be called P instead.

Stroustrup called it C with Classes, maybe he didn't want to call it P (don't blame him) but someone else called it C increment (++) and it stuck.

 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 3331
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: C++ interview questions that do not suck
« Reply #11 on: May 07, 2014, 07:33:02 am »
Here you have an UML diagram.
Give the classes.h file.

Of the UML diagram of class A, write the constructor and destructor.
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 3496
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: C++ interview questions that do not suck
« Reply #12 on: May 07, 2014, 07:38:24 am »
What sort of area is the person you're hiring going to be working in?

Most of the code I write is low level, embedded / driver stuff. A lot of the 'gotchas' are to do with the way the code interacts with the hardware... registers changing half way through being read, interrupts triggering at just the wrong time, that sort of thing. The hardware may have bugs of its own still to be found (hardware fault), or it may not be set up correctly (software fault). Stopping the CPU with a debugger doesn't also freeze the rest of the hardware on the board (and the hardware the board is connected to), so you can't just 'stop the world' and step through it to see where errors creep in.

Imagine, for example, that you're writing code that takes in a continuous stream of data from a reliable external device, processes it, and delivers the results to some other I/O port. Every so often, your outgoing data stream appears to have an error in it. Describe how you would approach such a problem.


Offline madshaman

  • Frequent Contributor
  • **
  • Posts: 699
  • Country: ca
  • ego trans insani
Re: C++ interview questions that do not suck
« Reply #13 on: May 07, 2014, 12:43:37 pm »

Any question that involves writing code is pointless. At best you get a small routine, hastily written by someone under pressure using a pen that doesn't support deleting mistakes or copy/paste. If they are unlucky it could be something they are not familiar with or they might make a mistake that a compiler would have caught and been easily corrected. There is no shame in googling for information, in fact it's better than relying only on your own experience much of the time.

I ask candidates to provide this before they come to their in-person interview, nothing helps me assess someone better than looking at how they code and/or design a system.

I've never asked a candidate to write code in front of me, but have been asked to write code myself plenty off times.

I see nothing wrong with this though.  Sure it's okay if a candidate needs to look something up, but getting flustered and not being able to perform under stress and time-pressure is something employers need an idea of sometimes; it does indicate a candidate's mastery to a degree.
To be responsible, but never to let fear stop the imagination.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17971
  • Country: nl
    • NCT Developments
Re: C++ interview questions that do not suck
« Reply #14 on: May 07, 2014, 12:56:06 pm »
When hiring someone I always have the person take a test. Not to determine the absolute level of competence but just to see if they can do what they say they can do. There are lots of people out there which are full of BS. It prevents wasting time with firing someone in their trial period.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline aroby

  • Regular Contributor
  • *
  • Posts: 206
  • Country: us
Re: C++ interview questions that do not suck
« Reply #15 on: May 07, 2014, 01:00:04 pm »
About 10 years ago I was talking with a guy who knew about the embedded code in tank fire control systems. He told me that even to correct the spelling mistake in a string on the display would required over £1.5m of testing.

That's just bad architecture.  The string should be externalized so you don't have to touch the code.
 

Offline _Sin

  • Regular Contributor
  • *
  • Posts: 247
  • Country: gb
Re: C++ interview questions that do not suck
« Reply #16 on: May 07, 2014, 01:33:53 pm »
I get candidates to write some code in the interview, but I just hand them a laptop with a development environment on it. I don't rate asking people to write code down on paper with a pen as it's not how I'd expect them to ever work.

Programmer with a soldering iron - fear me.
 

Offline Neilm

  • Super Contributor
  • ***
  • Posts: 1434
  • Country: gb
Re: C++ interview questions that do not suck
« Reply #17 on: May 07, 2014, 07:26:13 pm »
About 10 years ago I was talking with a guy who knew about the embedded code in tank fire control systems. He told me that even to correct the spelling mistake in a string on the display would required over £1.5m of testing.

That's just bad architecture.  The string should be externalized so you don't have to touch the code.
Still have to prove it it would not make a difference. Given that it is embedded there were probably all sorts of other issues - checking files linked correctly and did not affect the control algorithms.


Much better to ask them to bring examples of code they have written and then talk about it. You want someone who will do a good job, you don't so much care how they get there, so look at the end result. Working, debugged code will tell you a lot more than something they scribbled out in ten minutes.


Only if they coded at home. Anything from a company would be copywrited by that company (and in cases I have worked in - Classified)
Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe. - Albert Einstein
Tesla referral code https://ts.la/neil53539
 

Offline retrolefty

  • Super Contributor
  • ***
  • Posts: 1606
  • Country: us
  • measurement changes behavior
Re: C++ interview questions that do not suck
« Reply #18 on: May 07, 2014, 10:39:40 pm »
Best question: Who created C++
Best answer:  Barney Shoestrap.
 

Online AG6QR

  • Frequent Contributor
  • **
  • Posts: 810
  • Country: us
    • AG6QR Blog
Re: C++ interview questions that do not suck
« Reply #19 on: May 07, 2014, 10:51:41 pm »
Any question that involves writing code is pointless. At best you get a small routine, hastily written by someone under pressure using a pen that doesn't support deleting mistakes or copy/paste. If they are unlucky it could be something they are not familiar with or they might make a mistake that a compiler would have caught and been easily corrected. There is no shame in googling for information, in fact it's better than relying only on your own experience much of the time.

At my workplace, we occasionally do some collaborative coding and brainstorming on the whiteboard.  Of course the details of the semicolons and other minor things that would be caught by the compiler don't matter.  But an employee who can clearly communicate an algorithm on the whiteboard is more valuable than one who cannot.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6004
  • Country: us
Re: C++ interview questions that do not suck
« Reply #20 on: May 08, 2014, 12:08:58 am »
Not an interview question but a quiz. A C/C++ program has two adjacent lexical tokens (on the same line). Inserting a space character between them changes the semantic of the program. How come?
Drain the swamp.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: C++ interview questions that do not suck
« Reply #21 on: May 08, 2014, 01:13:26 am »
Not an interview question but a quiz. A C/C++ program has two adjacent lexical tokens (on the same line). Inserting a space character between them changes the semantic of the program. How come?

compiler or preprocessor?

and will adding a comment /*blah*/ do the same thing? (preprocessor changes the comments with spaces)
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3066
  • Country: us
Re: C++ interview questions that do not suck
« Reply #22 on: May 08, 2014, 01:31:56 am »
Quote
this question very clearly separated out candidates into two distinct groups.  Those who thought it was trivial [...], and those who didn't have a clue where to begin
Questions that make THAT division are pretty easy to create, although you should perhaps avoid cliches ("binary search") that could be specifically studied before the interview.

But is it possible to do significantly BETTER than that with an interview question?  To divide the people who know C++ into those who REALLY know their C++ from the people who know Python and Perl but took a quick glance through a C++ book.  Or does it really matter?  For your hypothetical geometric application, I'd rather have someone who understood geometry than someone who could argue obscure C++ syntax standards issues.  I've hired people who weren't well-educated in the language I expected them to program in.  I've BEEN hired to program in a language I wasn't well educated in.  And surely there is a big difference between some who you expect to write embedded C++ code while carefully avoiding "expensive" C++ features and unimplemented libraries, vs someone you expect to write "standard windows L&F C++ using the XYZ GUI library."
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: C++ interview questions that do not suck
« Reply #23 on: May 08, 2014, 01:43:02 am »
Quote
this question very clearly separated out candidates into two distinct groups.  Those who thought it was trivial [...], and those who didn't have a clue where to begin
Questions that make THAT division are pretty easy to create, although you should perhaps avoid cliches ("binary search") that could be specifically studied before the interview.

But is it possible to do significantly BETTER than that with an interview question?  To divide the people who know C++ into those who REALLY know their C++ from the people who know Python and Perl but took a quick glance through a C++ book.  Or does it really matter?  For your hypothetical geometric application, I'd rather have someone who understood geometry than someone who could argue obscure C++ syntax standards issues.  I've hired people who weren't well-educated in the language I expected them to program in.  I've BEEN hired to program in a language I wasn't well educated in.  And surely there is a big difference between some who you expect to write embedded C++ code while carefully avoiding "expensive" C++ features and unimplemented libraries, vs someone you expect to write "standard windows L&F C++ using the XYZ GUI library."

Agree with this.

The place I ended up with didn't do the online test like the others did. Pretty much they asked me for sample code and flew me there for an interview, got some problem solving generic questions, some C++ proficiency quick questions and that was it.

The problem solving is what got me the job. The C++ proficiency is what closed the deal.

Edit: but I'm oversimplifying, there was more to it than just that, and the combination of all of it is probably what got me the job.
« Last Edit: May 08, 2014, 02:02:51 am by miguelvp »
 

Online AG6QR

  • Frequent Contributor
  • **
  • Posts: 810
  • Country: us
    • AG6QR Blog
Re: C++ interview questions that do not suck
« Reply #24 on: May 08, 2014, 02:15:35 am »
Quote
this question very clearly separated out candidates into two distinct groups.  Those who thought it was trivial [...], and those who didn't have a clue where to begin
Questions that make THAT division are pretty easy to create, although you should perhaps avoid cliches ("binary search") that could be specifically studied before the interview.

But is it possible to do significantly BETTER than that with an interview question?  To divide the people who know C++ into those who REALLY know their C++ from the people who know Python and Perl but took a quick glance through a C++ book.  Or does it really matter?  ....

Agree with all you said.  And I think it certainly IS possible to probe into how well a person knows the nuances of the language, if you consider that important.  In the context I was talking about, as you suggest, that's not what I was looking for.  For my context, knowledge of the application area is far more important than knowledge of the language subtleties. 

The right algorithm, implemented in a straightforward and not-super-smart way, usually outperforms a brilliantly slick and clever implementation of a less-than-optimal algorithm.  And it's probably easier to maintain, too.


But sometimes you want a brilliantly slick and clever implementation of the right algorithm.  I can imagine that, if you're working in an embedded system under tight memory constraints, you might want to hire someone who is aware of how to get the most out of the compiler and processor under those circumstances.  Another reason to hire someone who really knows the language inside-out is if you're hiring someone to write a compiler.

It all depends on what the employer is looking for.  Which is why it's hard to give good specific interview preparation advice, other than to know your potential employer well, and know the things your resume says you know.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf