Job Interview In Two Days -- Tips?

[manasecret]

I've got my first job interview pretty much ever Thursday morning. I've had the same job since my senior year in high school, and kept it all through college and immediately after college. Along the way I was promoted and did more and more, to the point where I'm pretty much on top of the heap here. But it means I never had an interview for a job. I have had a couple other interviews, but for less critical things.

So, I'm nervous! I try not to be, but just can't help it. I'm preparing -- reading the company website, getting advice from everyone and your grandma on the internet, getting sample questions and working out some general answers in my head. But it's nerve-wracking. The CEO, President, and two managers will be part of the interview.

But I'm trying to remember, that I'm good enough, I'm smart enough, and doggone it, people like me!

Any tips? How would you answer some of the questions, such as --

What is your greatest weakness?
Where do you see yourself in five years? Ten Years?
What do you consider your two or three greatest accomplishments?

[Jason1]

I have never had a good answer for the "greatest weakness question" I will be curious as to what others say.

As for "Where do you see yourself in 5 to 10 years" I always say something along the lines as working for a company, possibly this one, where I can continue to learn new skills and work hard to advance within the company.

For 2 or 3 greatest accomplishments, that shouldnt be too hard. Graduating college, and the like.

[Teuthida]

What is your greatest weakness?

"Kryptonite." And then immediately bend a steel bar. Works every time.

Where do you see yourself in five years? Ten Years?

"According to my last time travel trip..."


What do you consider your two or three greatest accomplishments?

"Did you not see me bend that steel bar? And I time travel for goodness sake!"


Eh, just be honest. What's the job if I may ask?

[Typhoid]

I've never been asked any of those questions for any job interview.
All the interviews I've had have just been hanging out with the employer getting to know eachother, and seeing if you actually get along.

My advice would be to just not panic. Just chill out, be yourself. You don't want to get hired on the basis they think that you think you're infallible. If you have a flaw, say it. Just answer everything legitimately, and be yourself. If they don't hire you because you were acting like yourself, fuck 'em.

[Xantar]

What is your greatest weakness?

Any counselor will tell you never to answer this question honestly. I actually have done just fine by saying up front that I'm very blunt. But if you want a good compromise answer, try something like, "I know from prior experience that (insert menial task like filing or answering the phone) is not my favorite part of the day. I understand it's an important part of the job and I will do it, but I can't tell you in all honesty that I'll greatly enjoy it."

Where do you see yourself in five years? Ten Years?

You're only in your 20s, right? Then the correct answer is, "At this stage in my life, anything could happen." Of course, every interviewer already knows this, and the point of the question is to find out if you have ambition and where you are likely to direct it. A pretty reasonable answer would probably be, "In five years, I could be in graduate school looking to go further in this field." Or, "I see myself in a position of responsibility supervising some other employees."

What do you consider your two or three greatest accomplishments?

Sorry. Can't answer that for you. It's completely individual and personal to you. The best advice I can give is that at this point in the interview, you have probably been asked, "What is your greatest strength?" So pick some accomplishment that reinforces that.

My last tip is to be candid and be yourself. That doesn't mean you have to spill all your shameful secrets, and it doesn't mean you shouldn't try to present the best side of yourself. But at the end of the day, you're not going to deceive them outright about anything, and you shouldn't really try. Interviewers usually appreciate it if they get the sense that you're being honest and straightforward with them. And if they don't, maybe you wouldn't have fit in so well with that company anyway.

[Neo]

I have never had a good answer for the "greatest weakness question" I will be curious as to what others say.



There are only a couple good ways to answer this. And trust me, I've interviewed a ton of people. The best way is to turn your weakness into a strength. You have to say something like "I'm a bit of a perfectionist, in that I probably go over my work too many times to make sure it's accurate." Don't say you don't like to answer phones if that's part of the job. Honesty is not always the best policy.

[Neo]

You're only in your 20s, right? Then the correct answer is, "At this stage in my life, anything could happen."



I disagree with this, too. Anyone who tells me they want to leave to go back to school or they want to be a teacher is basically shooting themselves in the foot. We want people who are going to be committed to working here; it takes too long to train people. We actually had a girl tell us she wanted to be a teacher but wasn't able to get a job in that field. Of course we aren't going to hire her, because she's just going to bolt when when she finds what she really wants.

[Teuthida]

There are only a couple good ways to answer this. And trust me, I've interviewed a ton of people. The best way is to turn your weakness into a strength. You have to say something like "I'm a bit of a perfectionist, in that I probably go over my work too many times to make sure it's accurate." Don't say you don't like to answer phones if that's part of the job. Honesty is not always the best policy.

That was my first thought but figured they'd expect a canned answer like that. "I work too damn hard." "I have a compulsion to get along with my coworkers." "I tend to do whatever my boss tells me too. I sodomized an ostrich at last job. I'm that obedient."


I disagree with this, too. Anyone who tells me they want to leave to go back to school or they want to be a teacher is basically shooting themselves in the foot. We want people who are going to be committed to working here; it takes too long to train people. We actually had a girl tell us she wanted to be a teacher but wasn't able to get a job in that field. Of course we aren't going to hire her, because she's just going to bolt when when she finds what she really wants.

I dunno. The last time I had to answer that question I was truthful and now I'm about to attain what I said I would be doing five years from then. Of course there was no way I was going to stay at that crap job for five years. I think I lasted five months. But yeah, if you really want the job, lie like crazy. If you want to be a teacher or go back to school, lie and you'll still get the job. How is that better? Why would you prefer someone who lies that they want to stay there but will bolt at anytime as opposed to someone who's truthful and you'll know exactly how long they might be there for?

Then again I'm biased against jobs that interview you like that where you can easily be replaced and they care more about your personality and compliance than your work. I liken it to a beauty pageant without the swimsuit competition. I suppose you need that though if don't have prior experience for the job you're applying for.

[manasecret]

Sweet advice guys. I am very impressed. And Teuth, with your nerd cocktail articles and your posts here, I have come to the conclusion that you are a comedic genius.

I'll edit this post with more thoughts in just a minute.

[Neo]

If you want to be a teacher or go back to school, lie and you'll still get the job. How is that better? Why would you prefer someone who lies that they want to stay there but will bolt at anytime as opposed to someone who's truthful and you'll know exactly how long they might be there for?


Well either way the person's going to leave, right? As an employer, I'd rather them tell me up front. But from your perspective, you don't want me to know that you're going to bolt. So LIE, LIE, LIE! :mischief:

[manasecret]

Well that was a long minute... Sorry I didn't get back two days ago! I ended up preparing and writing answers all that day, in between getting my stomach out of my throat.

So, the interview is over... aaaaaaaanddd...

It went well! It's all almost a blur at this point, but going in I was hugely nervous from the build-up. The same day as my last post, I found out it was a joint interview with five people, including the CEO and President.

:faint:

But the president put me immediately at ease. They started the interview by describing their company and history, and he was an amicable guy, so it was a great relaxing start. Also, the CEO wasn't there and wasn't going to be there for most of the interview!! So a big weight off right up front. It let me be myself and confident.

Two biggest pieces of advice that I got which worked amazingly:

1. Make three key talking points that you know the company wants in that position. And the amazing part is that you don't even have to guess what those are, the company will tell you themselves! Before the interview, ask the H.R. person or whoever you're in contact with, what are the three key things needed to be successful for this position. Think about how you can provide those three key things, fill it out with examples, and focus on those. So if you get thrown a curveball that you're not sure how to answer, you can always work it back into your talking points. Kind of like politicians do. Very effective.

2. In the same email with the H.R. person, ask who will be involved in the interview. Then do as much research as you can on them. I wasn't a big fan of LinkedIn before this interview, but I am now. They specifically said they were impressed that I knew quite a lot about each of them and how they got to their position. The best part for me is that it simply brought these guys with big titles back to earth, because I found ways I could relate to them. It turns out the President started as an intern at the company in college, and worked his way up from there. That is pretty much exactly how my career has gone, so I had an immediate connection.

So, I'm hopeful about my chances, but there were certainly some things I could have answered better or done slightly better in the pseudo-code test. I'm supposed to find out in a week or two....

[BreakABone]

Since this thread is here, just set up a phone interview.

I've never done one of those before (properly anyhow, I've had "interviews" over the phone but generally as a way to set up another interview) so how is that different?

[manasecret]

Never done one, but have read some advice on it. Biggest advantage you have on a phone interview, is that it's open-book. You can have as many sources as you need right in front of you. This apparently can also work against you if you don't take advantage of it, because at the same time they may expect you to have all your sources in front of you.

Update on my interview: I was interviewing for a software engineer position. Turns out within two hours of the interview ending, they sent me an email saying they all discussed that they think I would be a better fit as a support engineer for them, also an open position. A strange place for me to be in, because I would really like to work for the company, especially as a software and/or electronic engineer. And I've always thought of support engineering as engineering lite. Would it be challenging enough for me?

I spoke to my dad about what he thinks about support engineers since he has a long history in an industry of engineers, and he says it can fall into two categories -- one where it really is engineering lite, just basically answering the exact same questions from users over and over, or on the other hand having a large rewarding influence, where you get to pass on the user's needs to really affect a project. Or some such.

[Vampyr]

I'm currently working as a software developer at Dell. One of the most important things to do in an interview for a software development position is to talk about projects you've worked on in your own time, to show you're passionate about programming.

I didn't have to write any code in my interview, though. Seems like it would be stressful.

[gekko]

Pseudo-code test? Were you going for a programming interview? Those are generally a little different than interviews for other careers.

[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]

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?

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]

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]

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]

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? :(

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.