Interviews

[Jessie]

For you techie/geeky/nerdy types.  If you were interviewing/being interviewed for a position requiring technical skill, with programming, for instance, what would you expect the interview to be like?

Are you generally asked to somehow display your abilities, or are you able to rest on your education/experience?  Do you have stories about what you'd consider to be an average or normal interview?

Thank you in advance.

[BigDun]

Put a gun to his head, have some hot Russian chick start giving him a blow job, and tell him that he has 3 minutes to crack a secure federal database or you kill him.

[Jessie]

I will totally do that!

Actually, Carroll's about to start looking for a job in Louisville.  He's only had one 'real' job since college, and that's the one he has now.  They have really weird interview procedures.  For example, when they bring someone in to their area for an interview, everyone gets together and talks to the person at once.  Except the boss.  She doesn't ask any questions at all.  And they ask like, "What do you like to do" and "What have you done in the past" but never "X hypothetical situation has occurred, how would you handle it" or anything like that.

Because they're so weird, he's not sure really what to expect in a non-government kind of job, or how to prepare.

[BigDun]

Having recently been hired by a government committee, I can say that the hiring process in the private sector is quite different. But then again, private industry doesn't have a set methodology for interviewing like the government does. It really depends on who is doing the interview. Usually you get an interview with the HR folks who just want to see if you are a good fit for the corporate culture. Then you get an interview with the Manager of the group and a few of their flunkies. This is where the interview may get technical.

Then again it may not. But they will almost always ask you questions like:

Explain a technical hurdle you experienced in one of your previous projects and how you overcame it.
What do you consider the most difficult/easiest aspects of programing/spec'ing/documenting?
How well are you able to handle requests for change or changes in project scope?

and the grand daddy of them all-

Let's pretend that you are given a project to implement a (make up a system like inventory, HR app, factory automation, etc, whatever is likely for the position he will be interviewing for). How would you go about attacking such a project.

Most of the time they aren't looking for specific technical prowess. If you have the coding chops, they'll know. What they are more interested in is how the applicant approaches issues. What structures do they put in place to break projects down into manageable parts. And how do they ensure quality through project scope changes, and ensuring proper documentation prior to and after fact.

Hope that helps.

[Jessie]

Thanks a lot.  I'll pass that along.

[nishi]

this is where i want to read alice's brother's letter to that guy that he was hoping would hire him. i think we can all continue to learn a great deal about the workplace from that letter.

[Jessie]

I think I vaguely remember a letter, but I can't remember details.

[ReBurn]

In the last interview I had, which was with a private sector company, they asked me some questions relating to problem solving abilities just like BigDun mentioned. They also some very pointed questions about the technologies that they were using, like what interfaces are used for in .NET and how to build web services in .NET. They also had some people come in and ask me some questions about concepts relating to general patterns, such various questions about why someone would use object-oriented programming patterns over traditional procedural patterns and why someone might use a model-view-presenter pattern when building user interfaces.

One thing I've found recently as I'm testing the waters is that people are looking for very specific skillsets, so he'll need to know how to speak intelligently about the skills they are asking for.

[swolt]

I ask people if they know how to edit the registry. If they say yes, I hire them.

[BigDun]

Usually the really tech questions they ask are actually quite hidden in the way that they are formed. Something like an off the cuff question such as "Did you notice how global variables' persistence is retained across different projects in .NET 2005?"

This question is something that could be thrown out as a red herring, since global variables don't have persistence across projects.

But questions like this are things that are thrown in as "on a side note" that are actually used to test the applicants knowledge.

On a positive note, simply stating that "I didn't know that .NET 2005 had persistent global variables across projects." would both be a true statement (because they don't) and a show of the fact that you aren't sucking up and answering questions in a way that that shows you think you know everything. Truthfully, showing where your knowledge is lacking is a better show of your ability than trying to show everything you know.

Again, if you have programing skilz, don't worry about showing them off. They will shine or they won't. The company's needs may not require shinny programing skilz.

Truthfully, I can teach a well structured mind programming skilz. I can't teach a shiny programmer how to think with structure.

[ReBurn]

Red herrings suck balls. I remember in my first interview for a programming job this jerk of a guy kept throwing them at me. "How do you write a top inner join iin SQL?" "Are you saying you can't, or are you just afraid to admit you don't know how?" What a jerk. When the lady called to offer me a data analyst job I told her I wasn't going to work for the same company as that guy. God he was a jerk.

And I agree, you can't teach someone to think with structure. I've had to try to teach OOP stuff to mainframe COBOL developers used to writing procedural code only and they just can't grasp why the "pine tree is still a tree" thing is important. Forget anything asynchonous.

/geek on

And in the Composite Application Block in .NET 2.0, you can persist objects across projects loaded at runtime in the same solution through the root workitem's Items collection. CAB is hard to learn, but that and ObjectBuilder allow for some wicked agile and modular programming. Nasty assembly references be damned!

/geek off

[Dry then Catch]

I just try to look my most Asian

[Gamplayerx]

Hahahaha!  That was a most unexpected and much needed laugh. Thanks, Catchr!

[Jessie]

Hahahaha!  That was a most unexpected and much needed laugh. Thanks, Catchr!

Oh my god.  Me too.  HAHA

[Jessie]

Are you all getting that tie rental ad?  It's like the Netflix of fashion!

[BigDun]

/geek on

And in the Composite Application Block in .NET 2.0, you can persist objects across projects loaded at runtime in the same solution through the root workitem's Items collection. CAB is hard to learn, but that and ObjectBuilder allow for some wicked agile and modular programming. Nasty assembly references be damned!

/geek off

See, this just goes to show you how you can trip yourself up by pretending to know about stuff you don't have clue about. I only heard about .NET 2005 because I was in a meeting yesterday and someone asked another person if they had managed to load it on their computer at work. And I haven't worked in a procedural language in 10 years. I don't know shit about the persistence of global variables. I just threw some words together that I knew would sound good in the same sentence.

I wouldn't recommend doing this in an interview.

[ReBurn]

/geek on

And in the Composite Application Block in .NET 2.0, you can persist objects across projects loaded at runtime in the same solution through the root workitem's Items collection. CAB is hard to learn, but that and ObjectBuilder allow for some wicked agile and modular programming. Nasty assembly references be damned!

/geek off

See, this just goes to show you how you can trip yourself up by pretending to know about stuff you don't have clue about. I only heard about .NET 2005 because I was in a meeting yesterday and someone asked another person if they had managed to load it on their computer at work. And I haven't worked in a procedural language in 10 years. I don't know shit about the persistence of global variables. I just threw some words together that I knew would sound good in the same sentence.

I wouldn't recommend doing this in an interview.

Well, technically you are still right since CAB isn't something you get by default. So I'm sure that means something. Maybe not to Carroll...

[JJ]

For you techie/geeky/nerdy types.  If you were interviewing/being interviewed for a position requiring technical skill, with programming, for instance, what would you expect the interview to be like?

Are you generally asked to somehow display your abilities, or are you able to rest on your education/experience?  Do you have stories about what you'd consider to be an average or normal interview?

Thank you in advance.

Usually your first interview will be an interview with HR reps as just a basic screen, they will read off a list and may ask you about what you did at job X or job Y on your resume. My experience has been that a first interview won't have technical questions and will be a list of banal HR type questions about your strengths and weaknesses and what you can contribute to the organization. Even when there is technical staff present, you won't get more technically detailed than just mentioning technical subjects.

Depending on how they set up the interview, your second interview may be with a higher ranked person or a technical supervisor of some sort.

You generally want to give the impression that you understand their organization and what they are doing, and are aware of what contributions you can provide for them. You need to demonstrate "I achieved feat X at place Y and learned this and that and this applies to you because for you I can do thing Z and thing Q" initially to HR and then hammer it home with any higherups that are present.

Or it could be a totally informal interview based on whether your boss likes you if your skill set is homogenous enough to other candidates.

So, research the company, research the position, get into thinking about describing your skills as they apply to the position in question.

tarrant84 from TF knows a lot about this stuff, I am paraphrasing his advice which I have found to be very practical.

[Alice]

Letter my brother wrote?

[Jessie]

This is all great advice, and we appreciate it!

[Alice]

You could also follow the other method that was on this board once.  Just have him lie about what he can do, based on the criteria of the job.  Then he can just pick up a book and learn whatever it is he doesn't know in a few days I'm sure.

[Beefy]

Also, Hatt might have some good advice on this topic.

[JJ]

You could also follow the other method that was on this board once.  Just have him lie about what he can do, based on the criteria of the job.  Then he can just pick up a book and learn whatever it is he doesn't know in a few days I'm sure.

Yeah that'll work seamlessly when he is shockingly ignorant in discussions with his coworkers.

Hell, I have that ignorance sometimes when I talk to electricians and instrumentation guys, and I find it kind of embarrassing, but it's not a big deal in my situations. I also run across people that are clued out in various ways frequently. So I guess I'm talking myself into the position that some learning can take place after getting the job, but that it's a much better idea to have some relevant experience and knowledge to begin with even if it's just to not look like a total idiot all the time. Beyond that, if you know what you are doing, you can be confident in the results and services that you provide to your employer, and you'll struggle a lot and have poor productivity if you are incompetent.

[Bennyhana]

You could also follow the other method that was on this board once.  Just have him lie about what he can do, based on the criteria of the job.  Then he can just pick up a book and learn whatever it is he doesn't know in a few days I'm sure.

Yeah that'll work seamlessly when he is shockingly ignorant in discussions with his coworkers.

Hell, I have that ignorance sometimes when I talk to electricians and instrumentation guys, and I find it kind of embarrassing, but it's not a big deal in my situations. I also run across people that are clued out in various ways frequently. So I guess I'm talking myself into the position that some learning can take place after getting the job, but that it's a much better idea to have some relevant experience and knowledge to begin with even if it's just to not look like a total idiot all the time. Beyond that, if you know what you are doing, you can be confident in the results and services that you provide to your employer, and you'll struggle a lot and have poor productivity if you are incompetent.

Right.  You may not have been around for what/who she's referencing.

[dazie]

You could also follow the other method that was on this board once.  Just have him lie about what he can do, based on the criteria of the job.  Then he can just pick up a book and learn whatever it is he doesn't know in a few days I'm sure.

Yeah that'll work seamlessly when he is shockingly ignorant in discussions with his coworkers.

Hell, I have that ignorance sometimes when I talk to electricians and instrumentation guys, and I find it kind of embarrassing, but it's not a big deal in my situations. I also run across people that are clued out in various ways frequently. So I guess I'm talking myself into the position that some learning can take place after getting the job, but that it's a much better idea to have some relevant experience and knowledge to begin with even if it's just to not look like a total idiot all the time. Beyond that, if you know what you are doing, you can be confident in the results and services that you provide to your employer, and you'll struggle a lot and have poor productivity if you are incompetent.

Right.  You may not have been around for what/who she's referencing.

let's not go there mmkay?