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.
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.
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.
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.
Thanks a lot. I'll pass that along.
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.
I think I vaguely remember a letter, but I can't remember details.
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.
I ask people if they know how to edit the registry. If they say yes, I hire them.
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.
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
I just try to look my most Asian
Hahahaha! That was a most unexpected and much needed laugh. Thanks, Catchr!
Quote from: Gamplayerx on April 11, 2007, 06:33:15 AM
Hahahaha! That was a most unexpected and much needed laugh. Thanks, Catchr!
Oh my god. Me too. HAHA
Are you all getting that tie rental ad? It's like the Netflix of fashion!
Quote from: ReBurn on April 10, 2007, 10:47:51 PM
/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.
Quote from: BigDun on April 11, 2007, 07:42:24 AM
Quote from: ReBurn on April 10, 2007, 10:47:51 PM
/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...
Quote from: Jessie on April 10, 2007, 07:46:14 PM
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.
Letter my brother wrote?
This is all great advice, and we appreciate it!
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.
Also, Hatt might have some good advice on this topic.
Quote from: Alice on April 11, 2007, 09:55:45 AM
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.
Quote from: JJ on April 11, 2007, 10:37:53 AM
Quote from: Alice on April 11, 2007, 09:55:45 AM
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.
Quote from: Bennyhana on April 11, 2007, 11:14:33 AM
Quote from: JJ on April 11, 2007, 10:37:53 AM
Quote from: Alice on April 11, 2007, 09:55:45 AM
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?
Did said individual have a cavalier attitude towards employment?
Quote from: JJ on April 11, 2007, 12:36:56 PM
Did said individual have a cavalier attitude towards employment?
I said we weren't going there!
I wanted to point out earlier that the red herring questions are an unfortunate side effect of having people who bullshit (read: lie) through interviews, but I didn't want to drudge that subject up.
Quote from: Alice on April 11, 2007, 09:50:49 AM
Letter my brother wrote?
didn't you post a letter that he wrote (aside: do you even have a brother?? i could be totally misremembering this. i know for a fact that i'm speaking of something that happened well over a year ago) trying to get a job as... a cook? something. where he waxed rhapsodic about not actually having any experience whatsoever, but that he thought that the job would be really cool, and so he should get it.
thank god jessie remembers something similar.
I remember that, too, though out of context. It could very well have been anyone's letter as far as I can remember.
Ohhhhhh, I know what you're talking about.
http://www.juntoonline.com/forum/index.php?topic=6845.0
And yes, I do have a brother.
I wonder if he got the job?
Damn you PE for not keeping us informed!
Tips from an HR type (copied from an old email):
As for interview tips... all of the "essentials" apply. If it's not an HR interview, they're going to do it based on how much they "like" you. (Which, as most companies have found out, is a very bad way to hire people...) However, if it's an HR interview it's going to be based on how much analogous experience you have to this particular position and how you feel it translates into what they do. Be that as I did HR, and I'm not an authority on making people "like" you, I am going to assume it's an HR interview and not a "spot" interview. ;)
The key really is to figure out what this company does and what you'll be doing for it. Ask yourself "If I were a client, why would I choose this particular place?" Let them know that you understand that and what they're all about. You really stand out if you seem like you understand the company, their philosophy, and what they're all about over a guy who just applied.
Next, figure out exactly what your position entails and what you've done in the past that will make you really good at doing it for them. Convey that information-- you've done what they're looking for, you've had success doing it, you understand what they want, and you're the person who can deliver it. They're hiring to fix something or because they have a need that has to be filled-- you have to be that "need" or "fix." "I used to do XYZ, with results ABC... which is analogous to what you do in your company."
Bottom line-- figure out what the company is all about and let them know you understand that. Next, figure out exactly what the job entails, and find stuff in your background that demonstrates you'll be good at doing it.
Finally, the red flags. Never ever bad mouth anyone. Keep everything real positive. "it sucked ass" should come out as "it was very challenging." You're leaving because you don't feel your current company is growing at a rate which will put you where you want to be, etc.... but keep everything positive.
---
All good advice.
aha! i now know why i thought it was you - because of the reference to The Reader. i knew it happened in chicago, and i couldn't put PE there.
you are a genius for finding it!
Quote from: nishi on April 12, 2007, 07:27:06 PM
aha! i now know why i thought it was you - because of the reference to The Reader. i knew it happened in chicago, and i couldn't put PE there.
you are a genius for finding it!
I was just glad I wasn't going insane and forgetting something hysterical that my brother had done.