Job Interview In Two Days -- Tips?

[manasecret]

Yep, pseudo-code test. I was put at a whiteboard and asked to write some pseudo-code for some scenarios that three of the head software engineers came up with.

But it was pretty simple, and they made a point to tell me to describe what I'm doing as I go along. They weren't looking for exact accuracy, just that you have some knowledge of programming.

For example, I mentioned I had created an object-oriented style class for my current job, so one asked me to write a "dog" class. You know the drill -- start with something like an "animal" class and define some inherited variables like "int legs" or "bool fur" that classes underneath it could define as needed. I think I did pretty well with the object-oriented test, and I did mention the private and public and inherited style variables for a class. But I forgot to flesh out the part where most variables in a class are private, while you have public functions that interface to those private variables.

Another test they gave me, since I had done some embedded work, was to write a program loop that controlled the temperature of an animal cage using a temperature chip and a heater. So I got busy writing the algorithm that checked for a temperature that was too cold, and turn on a heater. The mistake was that I was thinking only about how to convert the exact instructions they gave me into code, and not the overall features needed for such an animal cage temperature controller. For example, they pretty much said "Imagine you had an animal cage and you wanted to keep it from getting too cold, write that program." So I got busy writing when it gets too cold, and did it pretty well. Then after a few other questions, one guy said, "Do you see anything wrong with this program?" And since the actual code was good as far as I could tell, I wasn't thinking about the overall function. "What happens when it gets too hot?" Duhhhhhhhh, I forgot to check when to turn off the heater... Following instructions too literally... but it was just a pseudo-code test.

And yes, it was a software engineer position. You guys didn't have to do anything like that??

[gekko]

I was actually asking if it was a programming job because it's the only field I have ever heard of which is more like a test than an interview. I would've provided some advice had I known it was a programming interview.

But yes, whiteboard coding is quite common (and entire books have been published on the subjects). So are providing code samples, or taking a small programming test before they proceed with the interview process. Unless the company comes to you, I would be surprised if you ever avoid writing code entirely.

[Vampyr]

I think the reason I didn't have to write code was because when I originally interviewed it was for an intern position, and I was only a sophomore in college, so they weren't looking for me to have any amazing skills yet.

After interning for two years I didn't have to re-interview or anything and they had already seen about 2 years worth of my code, so I was just brought up to full time.

It sounds like you had some pretty legit questions though. I've heard a lot of stories about places asking really crazy programming questions that pretty much require you to know a certain vague algorithm before hand. Though I guess they could be testing how you try to reason things out.

[Vampyr]

Out of curiosity, do you know what languages/technologies you would be using on the job?

[manasecret]

Originally Posted by gekko

I was actually asking if it was a programming job because it's the only field I have ever heard of which is more like a test than an interview. I would've provided some advice had I known it was a programming interview.

But yes, whiteboard coding is quite common (and entire books have been published on the subjects). So are providing code samples, or taking a small programming test before they proceed with the interview process. Unless the company comes to you, I would be surprised if you ever avoid writing code entirely.

I wish I had mentioned it then! It was all of a sudden, so I didn't get to post as much as I wanted here. I did have fore-warning that I would have a whiteboard test, but I wasn't too worried about it.

What are a couple tips you would have given? Any thoughts on what I did right or wrong from the description I gave?

Originally Posted by Vampyr

Out of curiosity, do you know what languages/technologies you would be using on the job?

The languages I know they use are C and then Bash/Python. They do a lot of embedded work, so that's what the C is for. They also must interface their products with major OSes, including Unix/Linux, so that's my guess where Bash/Python come in.

I know next to nothing about Bash/Python, and I didn't mince words on that for better or worse. But I have done Javascript and PHP, which apparently are similar. They're scripting languages, and in my experience, scripting is like programming lite. I have no problem learning any language, let alone a scripting language -- and have the experience to show that.

[gekko]

I hate when you write a long post and it asks you to login when you're done, and loses everything you wrote. I'm going to bed, I'll re-type my damn post tomorrow

[Vampyr]

I wouldn't talk down so much to "scripting" languages. :P

From my experience I actually find compiled languages like Java (I know it's semi-interpreted) or C/C++ to be easier to understand conceptually. You have your objects and their functions and their access levels. Java is even easier since it only supports single inheritance. All the data types of your variables are known up front. I think they get a rep for being harder because they are so verbose and have a lot of boiler plate code to get things working.

Interpreted and dynamic languages like Python and Ruby require a lot more mental capacity on the part of the developer. You have to keep track of what types your variables are/could be, and since everything is interpreted and dynamic you can do crazy stuff like adding methods to classes at run time.

There are some top tier apps written in interpreted languages.

[manasecret]

Originally Posted by Vampyr

Interpreted and dynamic languages like Python and Ruby require a lot more mental capacity on the part of the developer. You have to keep track of what types your variables are/could be, and since everything is interpreted and dynamic you can do crazy stuff like adding methods to classes at run time.

I don't have a fine understanding of the differences between scripting and interpreted languages. Bash/Python were described to me as script languages, but if they are interpreted languages, then I'm all for them. Forth is an interpreted language at its heart, and it's one of the most powerful languages I've ever used. Much like you're saying, it gives you complete control of the types of your variables -- it just presents them as the 1s and 0s, you're expected to know what to do with them -- and entire functions can be redefined or added to on the fly, and more. It doesn't hold your hand.

There are some top tier apps written in interpreted languages.

If they are the way you make them sound, then I wouldn't doubt it. It's just that when I hear scripting, I think of things like DOS/XP scripting or Mac scripting or the Unix command line type scripting. There's certainly power there, but it's not any harder to learn than any deeper, low-level programming language.

[Vampyr]

People usually use scripting and interpreted interchangeably.

[gekko]

Originally Posted by Vampyr

Interpreted and dynamic languages like Python and Ruby require a lot more mental capacity on the part of the developer. You have to keep track of what types your variables are/could be, and since everything is interpreted and dynamic you can do crazy stuff like adding methods to classes at run time.

Sorry, but I have to disagree here. Keeping track of variable type is pretty trivial. If you were coding in C++ you're likely worried about performance, memory management, and thread safety which is considerably more complex (and that's excluding language issues). I've never heard of someone scripting in Python worried about cache coherency, or worried about casting a float to an int causing a CPU stall. Scripting languages have their place, but there's good reason why they're not used for high-performance code or large-scale distributed systems. Regardless, I would never expect to be interviewed on them, especially if they're using a language like C.

Anyways, on to the advice I typed up yesterday:

1) Read Programming Interviews Exposed, the book. It has a bunch of practice problems covering a variety of topics, and they tell you how you should approach many of the problems. If you happen to get a question from the book, just be honest and say you've seen it.

2) Talk through the whiteboard problems. If you sit there are stare at the board when you're thinking, the interviewer has no idea what's going on. Talk through what you're thinking. Also remember that most of these questions are chosen for a reason. For example, "Reverse all the words in a string in C" is really trying to find out if you understand null-terminated strings, how to walk an array with pointers, and see if you jump on the first algorithm that works or if you can find a more optimized one. So instead of just writing code on the board, saying extra stuff like "I'm using pointers to walk backwards through an array, which is tricky since I can point one past the end, but not one past the beginning, so my pointer will always be one element in front of what I'm referencing, like reverse iterators" not only tells me what you're trying to do (if you make a stupid mistake), but also tells me you understand some of the rules of pointers and arrays in C, and you know some implementation details of the STL.

3) Don't make assumptions. I've heard too many stories of interviewers asking a vague question just to see if you're going to rush into an implementation or find out all the details first (but keep in mind, I'm in Microsoft land). So if you get asked "Reverse a string", be sure to ask all the questions before you begin. What language? Null-terminated strings? Is this a reversal in place? If not, how are you handling the memory allocation? If you feel dumb asking the questions, then at least state your assumptions as you do (back to point 2), "So I'm assuming null-terminated strings in C here with an in-place reversal, right?".

4) Do the algorithm first. Make sure you have the algorithm down before you start coding. Not only does this look good, but whiteboard coding is top-to-bottom, which is not likely how you really code, so avoid the weird issue of forgetting a few steps and get it all down before trying to code it. There's been a few times where I've actually skipped the coding after getting the algorithm, since it was trivial at that point. Also, once you're done, go over the tests you were using before and make sure your code works. Always offer to do more tests (since sometimes that is the interview), but give them the opportunity to stop it and move on.

5) Pick 3 things you want them to know about you and make sure you tell them. Nothing is worse than leaving an interview for your dream job and realizing that you answered all the questions, but they never got a chance to learn what made you better than the next guy. Make sure you speak about your passions, your personal projects, etc. I generally think about it like this, all mathematicians should be able to add numbers together, you need to find out what makes one candidate better than the other. While some whiteboard questions are hard (some are designed to be impossible), assume everyone can solve them. Worry about standing out from the crowd.

[manasecret]

Originally Posted by gekko

Sorry, but I have to disagree here. Keeping track of variable type is pretty trivial. If you were coding in C++ you're likely worried about performance, memory management, and thread safety which is considerably more complex (and that's excluding language issues). I've never heard of someone scripting in Python worried about cache coherency, or worried about casting a float to an int causing a CPU stall. Scripting languages have their place, but there's good reason why they're not used for high-performance code or large-scale distributed systems. Regardless, I would never expect to be interviewed on them, especially if they're using a language like C.

Anyways, on to the advice I typed up yesterday:

1) Read Programming Interviews Exposed, the book. It has a bunch of practice problems covering a variety of topics, and they tell you how you should approach many of the problems. If you happen to get a question from the book, just be honest and say you've seen it.

2) Talk through the whiteboard problems. If you sit there are stare at the board when you're thinking, the interviewer has no idea what's going on. Talk through what you're thinking. Also remember that most of these questions are chosen for a reason. For example, "Reverse all the words in a string in C" is really trying to find out if you understand null-terminated strings, how to walk an array with pointers, and see if you jump on the first algorithm that works or if you can find a more optimized one. So instead of just writing code on the board, saying extra stuff like "I'm using pointers to walk backwards through an array, which is tricky since I can point one past the end, but not one past the beginning, so my pointer will always be one element in front of what I'm referencing, like reverse iterators" not only tells me what you're trying to do (if you make a stupid mistake), but also tells me you understand some of the rules of pointers and arrays in C, and you know some implementation details of the STL.

3) Don't make assumptions. I've heard too many stories of interviewers asking a vague question just to see if you're going to rush into an implementation or find out all the details first (but keep in mind, I'm in Microsoft land). So if you get asked "Reverse a string", be sure to ask all the questions before you begin. What language? Null-terminated strings? Is this a reversal in place? If not, how are you handling the memory allocation? If you feel dumb asking the questions, then at least state your assumptions as you do (back to point 2), "So I'm assuming null-terminated strings in C here with an in-place reversal, right?".

4) Do the algorithm first. Make sure you have the algorithm down before you start coding. Not only does this look good, but whiteboard coding is top-to-bottom, which is not likely how you really code, so avoid the weird issue of forgetting a few steps and get it all down before trying to code it. There's been a few times where I've actually skipped the coding after getting the algorithm, since it was trivial at that point. Also, once you're done, go over the tests you were using before and make sure your code works. Always offer to do more tests (since sometimes that is the interview), but give them the opportunity to stop it and move on.

5) Pick 3 things you want them to know about you and make sure you tell them. Nothing is worse than leaving an interview for your dream job and realizing that you answered all the questions, but they never got a chance to learn what made you better than the next guy. Make sure you speak about your passions, your personal projects, etc. I generally think about it like this, all mathematicians should be able to add numbers together, you need to find out what makes one candidate better than the other. While some whiteboard questions are hard (some are designed to be impossible), assume everyone can solve them. Worry about standing out from the crowd.

Good stuff. Thanks for taking the time to rewrite it.

Some of Number 3 and definitely Number 4 is where I think I stalled.

3) Don't make assumptions -- it's not quite in the vein of what you're saying, since they did say it's pseudo-code, so they weren't looking for a specific language for example. But for the animal cage temperature control, I wish I had taken a second and asked exactly what they wanted from it first.

4) Do the algorithm first -- Here I think is where I really could have done better. But I'm curious, do you mean writing down the algorithm, or doing it in your head? Forth has the benefit of looking like writing down an algorithm at the highest level of your code, for example with a temperature sensor and heater:

BEGIN
  ValidateTemp
  TurnOn?
  TurnOff?
AGAIN

And TurnOn? would be defined as something like:

: TurnOn?
  TempTooLow?
  IF
    TurnOn
  THEN
  ;

Which leaves a lot of the coding details out. Anyway, again, if I had stopped to think a little longer about the overall algorithm instead of rushing in, I think I would have done a lot better. In the case of the code I put there, I essentially started with just the TurnOn? algorithm, and completely left out the ValidateTemp and TurnOff? parts until they asked about them.

Testing -- the other part that got me. They asked me how I would test the algorithm, how would they know it worked when it got to them? I wasn't quite sure how to answer that, because it sounds like an obvious answer to me -- Just test it! -- but clearly they're looking for something. You said make sure to do tests, how would you do tests? Maybe, pick a certain temperature and make sure the algorithm works? Or for your example, choose a sample string and iterate through the algorithm?

[gekko]

Just for the record, this is attempt #2 again. Why do I keep getting logged out?

Originally Posted by manasecret

But I'm curious, do you mean writing down the algorithm, or doing it in your head?

Mainly write down enough so you can walk through a couple test cases and make sure the algorithm works before you test it. If I'm reversing a string, I want to make sure as I'm going through a couple test cases that I go in the same order and don't skip any steps. If you're speaking out load, it should be easy to follow. Just avoid worrying about syntax issues and make sure you have the correct algorithm.

You said make sure to do tests, how would you do tests? Maybe, pick a certain temperature and make sure the algorithm works? Or for your example, choose a sample string and iterate through the algorithm?

Generally, validate your inputs and test for edge cases (0, negative numbers, null pointers, etc.). In the case of reversing a string (from outside in), I would test 2 and 3 letter strings to handle the case of having the middle letter and not. Obviously ensure you didn't swap the null-terminator, and then move on to ensuring the user can't do anything stupid. Do you handle passing in a null pointer? What about an empty string ("")?

In the case of the heater, yes, pick values which should cause some expected result and ensure it happened. They might be asking a "What types of tests would you do" question which is just stating them, or they could ask you to write them (doubt it, seems like a waste of precious time). The other possibility is they want to see if you can design code in a way where it's easy to test.

If you're not familiar with writing test cases, find some articles on TDD and unit testing, and they should give you a good idea.