Programmers: Your favorite interview questions

[FightAndLive]

I haven't seen one these posts yet on this forum(if there is forgive me : )), but I figured to help out more people looking for programming work I would start a post for employers who are looking to hire new programmers what kind of questions you guys ask. I'm the technical director at a small game studio in LA, and were expanding so I also looking to see what everyone does so I can adjust accordingly.

Some of the basic questions I ask are:

What is global scope/local scope.

What is a template class

What is inheritance/polymorphism/etc.

Than some really basic logic stuff like whats a recursive function, etc etc.

Than I begin to ask a couple questions that are kind of off the wall because one thing I noticed is College graduates from big schools such as UCLA 9/10 can't figure stuff for themselves. Students are so used to stuff getting spoon fed to them, some of which is just nasty. One thing that really irritated me at one of the studios I worked at previously a couple of there senior programmers came to me and said "I don't know how to do xyz, can you help?" This normally is a pretty common thing, except when xyz happens over and over again and its something that easily be found by doing a quick google search.

I ask the interviewee if they can do something that 99% of the programmers out there can't do. They would obviously say I don't know, I would then ask them than to look it up for me on google and write out basic steps on how to get it done. Lets say I ask them how to register a custom Debug Engine in Visual Studio, first google search for "visual studio custom debug engine" which turns up http://msdn.microsof...4(v=vs.80).aspx , with a link to http://msdn.microsof...(v=vs.110).aspx. Even though the information on the latter article is actually wrong if they copied that I would be so happy. I've had guys sit there for 10 minutes struggling, and I feel that's kind of ridiculous. Every programmer in world should know how to use google :/.

Than depending on the level of the job, I would go into some more nitpicker things say in Unreal, Unity, D3D, whatever and if someone didn't know the answer I would ask them to google it and give me an explanation. I had actually had one guy who didn't graduate from a college, straight out of high school and he didn't know something I asked him, and than he immediately asked if he could go on google and look it up. I actually hired him on the spot and he ones of the best programmers I've ever had.

Anyway what kind of stuff do you guys ask?

[Lord Method Man]

Still an interesting topic.

[Louisifer]

Just because its old doesn't make it irrelevant, I've been quite entertained reading this thread and I missed out on it first time round :P

[snaphat (Myles Landwehr) Member]

^ Well at least I'm inadvertently necroing threads people like  :)

[Praetor]

That's my fault. I didn't notice that when I initially posted. But like I said before, I'm not even sure how I ended up on the thread to post since I only go to threads though the spy or thread lists.

 

not sure about that, i've read this thread this year or the year before because someone did replied to it so it was in the mini-spy.

[Rohdekill]

Funny how the OP complains about programmer answers to simple questions yet is unable to freakin' spell at a third grade level. 

[riahc3]

Hello,

Thank you for your answers.

Im not a guy thats really cares if code is efficient or not. I simply care that the code is clear to me (and other programmers if need be) and it works. Writing code in one line straight is just ugly and serves no other purpose.

[Kami-]

Hello,

Thank you for your answers.

Im not a guy thats really cares if code is efficient or not. I simply care that the code is clear to me (and other programmers if need be) and it works. Writing code in one line straight is just ugly and serves no other purpose.

Inefficient Code is acceptable to you huh?

 

Must make mental note to never deal with you :)

[Andre S. Veteran]

Im not a guy thats really cares if code is efficient or not. I simply care that the code is clear to me (and other programmers if need be) and it works. Writing code in one line straight is just ugly and serves no other purpose.

Efficiency of code has nothing to do with the number of lines of the source...

[+Nik Louch Subscriber²]

Im not a guy thats really cares if code is efficient or not.

 

Most ridiculous thing I've heard all day.

[+Biscuits Brown MVC]

Ya know, a few pages back I explained that we rely more on a conversational style interview that doesn't ask 'coding' questions because the developer you want to hire will reveal their abilities in how they converse. What we see above is a perfect example. raihc3 may likely have answered some random set of coding challenges but his simple statement above tells me so much more about how he will fit in my environment.  I'll take a less skilled developer if they have the right attitude, but pass on a more skilled candidate if they present themselves with in the way raihc3 did. 

[riahc3]

Hello,

Inefficient Code is acceptable to you huh?

 

Must make mental note to never deal with you :)

Understandable code > Inefficient Code any day of the week.

So Im guessing Brain#### is your choice of language, correct?

 

Efficiency of code has nothing to do with the number of lines of the source...

I used it as a common example; Using more lines than neccesary to do something simple is one way of inefficient code.

Another is declaring too much variables.

There are a lot of examples of inefficient code.

 

Most ridiculous thing I've heard all day.

Not really. Seems to me that you have no idea what you are talking about and have just posted to increase your post count

Efficient code is mostly only important in time critical programs. Other than that, its pretty much worthless in today's world and not a worrying factor.

In C/C++, however, it still does matter in certain cases for when example reserving memory space. You might end up with a very memory hogging calculator! :)

 

Ya know, a few pages back I explained that we rely more on a conversational style interview that doesn't ask 'coding' questions because the developer you want to hire will reveal their abilities in how they converse. What we see above is a perfect example. raihc3 may likely have answered some random set of coding challenges but his simple statement above tells me so much more about how he will fit in my environment.  I'll take a less skilled developer if they have the right attitude, but pass on a more skilled candidate if they present themselves with in the way raihc3 did.

Oh Im sorry, this was a job interview?

There are some things I would never do in a interview; For example, the inefficient code. Employeers love to hear that "the best code is the one that takes less memory and uses the min resources" and all the crap when at the end of the day, they dont look at the code and second, they just want results.

Zag L., let me ask you this, do you perfer the efficient coder that gives you a 2MB program in 6 months that you can put to the market and sell or do you perfer the inefficient coder that gives you a 40MB program in 2 months that you can put to the market and sell? Companies want results from their employees so they can win profit.

If you go with a, you are a programmer.

If you go with b, you are a businessman.

Being loyal to "the unspoken laws of programming" doesnt get the bills paid.

Anyways thats my outlook.

[firey]

Hello,

Understandable code > Inefficient Code any day of the week.

So Im guessing Brain#### is your choice of language, correct?

 

I used it as a common example; Using more lines than neccesary to do something simple is one way of inefficient code.

Another is declaring too much variables.

There are a lot of examples of inefficient code.

 

Not really. Seems to me that you have no idea what you are talking about and have just posted to increase your post count

Efficient code is mostly only important in time critical programs. Other than that, its pretty much worthless in today's world and not a worrying factor.

In C/C++, however, it still does matter in certain cases for when example reserving memory space. You might end up with a very memory hogging calculator! :)

Hello,

Oh Im sorry, this was a job interview?

There are some things I would never do in a interview; For example, the efficient code. Employeers love to here that "the best code is the one that takes less memory and uses the min resources" and all the crap when at the end of the day, they dont look at the code and second, they just want results.

There is also a time though you have to be smart with code.

Using too many variables isn't necessarily a bad thing.. it's worse to reuse variables for purposes outside of what you want to.  Reusing a m_counter variable for anything counter related is okay.  However to reuse m_name for anything string related is not okay.

You also don't want to make code take forever for other people to go through. I am sure if you asked anyone which code was better out of these two:

 

string output = "";

for (int m_val = 0; m_val < 100; m_val++) {
 output = (m_val % 3 == 0 ? "fizz" : "");
 output += (m_val % 5 == 0 ? "buzz" : "");
 console.writline(output.length > 0 ? output : m_val.ToString());
}

string output = "";

for (int i = 0; i < 100; i++) {
   output = "";
  
   if (i % 3 == 0) {
     output += "fizz";
   }

   if (i % 5 == 0) {
     output += "buzz";
   }

   if (output.Length == 0) {
      output = i.ToString();
   }

   Console.WriteLine(output);
}

Most people will go with the top one, as it does exactly what the bottom one does, in less lines, and is just as easy to read.  In the end, the compiler will generate roughly the same code (as both functions do the same) but they are much different in terms of size, and readability.

[riahc3]

Hello,

There is also a time though you have to be smart with code.

No doubt. There is no need to call a variable "thisisabignamedvariablewithaintegerhodlignvariable" instead of "num".

 

You also don't want to make code take forever for other people to go through. I am sure if you asked anyone which code was better out of these two:

string output = "";

for (int m_val = 0; m_val < 100; m_val++) {
 output = (m_val % 3 == 0 ? "fizz" : "");
 output += (m_val % 5 == 0 ? "buzz" : "");
 console.writline(output.length > 0 ? output : m_val.ToString());
}

string output = "";

for (int i = 0; i < 100; i++) {
   output = "";
  
   if (i % 3 == 0) {
     output += "fizz";
   }

   if (i % 5 == 0) {
     output += "buzz";
   }

   if (output.Length == 0) {
      output = i.ToString();
   }

   Console.WriteLine(output);
}

Most people will go with the top one, as it does exactly what the bottom one does, in less lines, and is just as easy to read.  In the end, the compiler will generate roughly the same code (as both functions do the same) but they are much different in terms of size, and readability.

I think its very very subjective to what is easier or harder to read. But I dont think you cant say yes or no because everyone has their own proper style of programming/coding.

The reason I would instantly choose the second is because its clear its a "if".....the other, programmers that have been programming a while (no pun intended :p ), catch it almost instantly. Others it might take a sec.

Readability is something very subjective and at the end of the day a opinion.

[+Biscuits Brown MVC]

Zag L., let me ask you this, do you perfer the efficient coder that gives you a 2MB program in 6 months that you can put to the market and sell or do you perfer the inefficient coder that gives you a 40MB program in 2 months that you can put to the market and sell? Companies want results from their employees so they can win profit.

If you go with a, you are a programmer.

If you go with b, you are a businessman.

Being loyal to "the unspoken laws of programming" doesnt get the bills paid.

Anyways thats my outlook.

 

We have an existing family of applications that are required to run on a very wide variety of hardware, some old, some new. We also have SLA's on how long a particular work unit can take to process as well as SLA's on overall daily productivity so efficiency is VERY important to us - not because we are 'programmers' but because we run a business that relies on the work getting done in certain time frames.

 

Additionally our release cycle allocates 25 coding days before we send the code to QA so I need both, efficient and expedient. I don't know what I would do with a 6 month development cycle.  

 

I'll be honest, guys like you stand out like a sore thumb in interviews. Maybe not where you are located, but certainly in my shop. There is difference between telling someone what you think they want to hear and having a thoughtful discussion about writing code and solving problems. We don't look for programmers, we look for solution providers, individuals that are passionate about the code they write, the way they work with other developers as well as our end users. They are valued contributors to the success of the company, not just a room full of 'coders'. Do I care if they can split a TIF image and do page manipulation in an interview. Nope... even though that might be their first problem. I care about how they think about problems and how they go about learning the things they don't know.

 

And please note, I work for a VERY large company here in the U.S. (something around Fortune 20 last I looked) so this isn't some mom and pop boutique software company making flapping birds apps. 

[snaphat (Myles Landwehr) Member]

This discussion about efficiency in these examples is really neither or nor there in terms of actual efficiency at the machine code level. Variables at the subroutine level are just a convenient notion for high level programmers. Programmers should be treating them as such and not trying to reduce the count of them through reassignment, etc. They don't exist outside of high level semantics anyway so it's a waste of time. Similarly, reducing redundant computations in simple branching code like in the case of FuzzBizz is another waste since the code will be hoisted and eliminated anyway. Most critically though, it's red herrings like these things that distract the programmer from focusing on optimizing things that are critical for performance: algorithmic design/complexity and critical paths.

 

This isn't to say that you should just outright try to make code that's potentially inefficient when transformed, but arbitrary reductions on variables and removing simple redundant computations in simple codes doesn't help. 

 

In terms of readibility, I prefer Firey's shorter code above. I feel it's clear and concise and I think interviewers would rather see that from a readability standpoint. From an optimization standpoint though, it is going to result in the use of more costly string concatenation operations that are avoided in the earlier examples. That's the type of thing I mean when I'm talking about algorithmic design: those are the types of things that matter versus removing variables and redundant computations. 

[Brandon Live Veteran]

Zag L., let me ask you this, do you perfer the efficient coder that gives you a 2MB program in 6 months that you can put to the market and sell or do you perfer the inefficient coder that gives you a 40MB program in 2 months that you can put to the market and sell? Companies want results from their employees so they can win profit.

If you go with a, you are a programmer.

If you go with b, you are a businessman.

Being loyal to "the unspoken laws of programming" doesnt get the bills paid.

Anyways thats my outlook.

 

What makes you think it takes longer to write efficient code? O_o

 

There's a difference between the absolute optimal solution and writing good versus bad code (or just as important, coming up with a good or bad design). I'd say an "efficient coder" is someone who can efficiently (i.e. in a timely fashion) write reasonably optimized, clear, maintainable code.

[Brandon Live Veteran]

There is also a time though you have to be smart with code.

Using too many variables isn't necessarily a bad thing.. it's worse to reuse variables for purposes outside of what you want to.  Reusing a m_counter variable for anything counter related is okay.  However to reuse m_name for anything string related is not okay.

You also don't want to make code take forever for other people to go through. I am sure if you asked anyone which code was better out of these two:

 

string output = "";

for (int m_val = 0; m_val < 100; m_val++) {
 output = (m_val % 3 == 0 ? "fizz" : "");
 output += (m_val % 5 == 0 ? "buzz" : "");
 console.writline(output.length > 0 ? output : m_val.ToString());
}

string output = "";

for (int i = 0; i < 100; i++) {
   output = "";
  
   if (i % 3 == 0) {
     output += "fizz";
   }

   if (i % 5 == 0) {
     output += "buzz";
   }

   if (output.Length == 0) {
      output = i.ToString();
   }

   Console.WriteLine(output);
}

Most people will go with the top one, as it does exactly what the bottom one does, in less lines, and is just as easy to read.  In the end, the compiler will generate roughly the same code (as both functions do the same) but they are much different in terms of size, and readability.

 

I wouldn't use either. At the very least, both are defining "output" at the wrong scope (which is why at first I thought you were trying to build up one long string versus a different one for each iteration of the loop). Or if you wanted to optimize it, you'd stop creating several strings on every iteration and use a single StringBuilder (assuming this is meant to be C#) or sufficiently sized buffer for your largest string.

[firey]

I wouldn't use either. At the very least, both are defining "output" at the wrong scope (which is why at first I thought you were trying to build up one long string versus a different one for each iteration of the loop). Or if you wanted to optimize it, you'd stop creating several strings on every iteration and use a single StringBuilder (assuming this is meant to be C#) or sufficiently sized buffer for your largest string.

Fair enough, in the end though you got what I was going for.  Yes I could have declared output as a string builder (and use the append function) as well as put it inside the for loop and have it all self contained.  It would of been a couple tweaks that yes would be more efficient, but in general it was the point of compressed but still easy to read.

[Andre S. Veteran]

F#, no variables:

let fizzBuzz = function
| x when x % 15 = 0 -> "fizzbuzz"
| x when x % 3 = 0 -> "fizz"
| x when x % 5 = 0 -> "buzz"
| x -> string x

[1 .. 100] |> List.iter (fizzBuzz >> (printfn "%s"))

:)

[snaphat (Myles Landwehr) Member]

What makes you think it takes longer to write efficient code? O_o

 

There's a difference between the absolute optimal solution and writing good versus bad code (or just as important, coming up with a good or bad design). I'd say an "efficient coder" is someone who can efficiently (i.e. in a timely fashion) write reasonably optimized, clear, maintainable code.

In terms of efficiency, focusing on trying to be clever when unneeded will take longer than not. A nice example of this is people trying to re-do well known recursive algorithms iteratively for efficiency. Most of the time, you are just dropping an explicit stack in such cases so the solutions are less efficient than using the implicit call stack via the iterative version.

 

 

 

F#, no variables:

let fizzBuzz = function
| x when x % 15 = 0 -> "fizzbuzz"
| x when x % 3 = 0 -> "fizz"
| x when x % 5 = 0 -> "buzz"
| x -> string x

[1 .. 100] |> List.iter (fizzBuzz >> (printfn "%s"))

:)

 

:D Fancy! Though to be fair everything would be in registers in either case

[riahc3]

individuals that are passionate about the code they write

Well, there is our main difference: Im not passionate about code, I just want to write code to get me paid :)

Also, my examples were obviously examples; Not real world numbers/figures :)

[Brandon Live Veteran]

In terms of efficiency, focusing on trying to be clever when unneeded will take longer than not. A nice example of this is people trying to re-do well known recursive algorithms iteratively for efficiency. Most of the time, you are just dropping an explicit stack in such cases so the solutions are less efficient than using the implicit call stack via the iterative version.

 

Well my point was that it's confusing and inefficient. It looked like he was trying to be clever by "reusing" the output variable, not realizing that reusing variables doesn't mean reusing objects or memory. So it was confusing to read because it was logically scoped incorrectly, while being no more efficient than having it scoped correctly.

 

For weighing a recursive implementation versus iterative, there are several factors to consider. But in the end, if it's a perf critical path, the real answer is "measure, measure, measure."

[Brandon Live Veteran]

Fair enough, in the end though you got what I was going for.  Yes I could have declared output as a string builder (and use the append function) as well as put it inside the for loop and have it all self contained.  It would of been a couple tweaks that yes would be more efficient, but in general it was the point of compressed but still easy to read.

 

By the way, if I saw that code in an interview, I'd ask you to explain why a StringBuilder would be better (since you seem familiar with it), or how many strings you're allocating in that original version.

 

As far as readability, I'd be fine with either. The first one should have parens around (m_val % 3 == ) and (m_val % 5 == ) though.

[firey]

By the way, if I saw that code in an interview, I'd ask you to explain why a StringBuilder would be better (since you seem familiar with it), or how many strings you're allocating in that original version.

 

As far as readability, I'd be fine with either. The first one should have parens around (m_val % 3 == 0) and (m_val % 5 == 0) though.

Honestly, I am not necessarily the best when it comes to syntax formatting.  However, the thing to keep in mind is those things can be learned and vary from place to place. 

The string builder is nice in that you aren't allocating a new string for each concatenation you do plus strings being concatenated. The string builders append function is adding them directly to the existing string and not allocating a new one (if I am not mistaken).  However I have not used the stringbuilder extensively nor worked on projects where memory is an issue.  I do try to keep my code clean and fluid, and remove unnecessary calls or functions, or use built in .NET solutions when possible.

 

From things I have seen though, if memory is not an issue the difference in speed between the raw concat and string builder is quite small.  It would take several thousand iterations of concatenation to really show the difference.  So from a raw preformance/speed test where memory isn't an issue.. the results are pretty close.  This is based off research I had done a while back.

 

This thread alone though goes to show the numerous ways to solve one problem and that people look for different things.

[Brandon Live Veteran]

Honestly, I am not necessarily the best when it comes to syntax formatting.  However, the thing to keep in mind is those things can be learned and vary from place to place. 

The string builder is nice in that you aren't allocating a new string for each concatenation you do plus strings being concatenated. The string builders append function is adding them directly to the existing string and not allocating a new one (if I am not mistaken).  However I have not used the stringbuilder extensively nor worked on projects where memory is an issue.  I do try to keep my code clean and fluid, and remove unnecessary calls or functions, or use built in .NET solutions when possible.

 

From things I have seen though, if memory is not an issue the difference in speed between the raw concat and string builder is quite small.  It would take several thousand iterations of concatenation to really show the difference.  So from a raw preformance/speed test where memory isn't an issue.. the results are pretty close.  This is based off research I had done a while back.

 

This thread alone though goes to show the numerous ways to solve one problem and that people look for different things.

 

Memory usage is one factor, though mainly it's about CPU usage (and memory / cache bandwidth). The posted implementation is doing a large number of small allocations and copies. Heap allocations have CPU cost, and in GC'd environments like this, can provoke a collection. Copies are relatively expensive. You're right that the difference is only noticeable if this is executed many times. But when you see loops, these are the sort of things you should be looking for.