Intensive technical interview process....What to do?

[tools2teach]

I've been a server\network\system administrator for 15 years. I have a all day intensive technical interview coming up. Part of the process which I am really concerned about is the scripting portion of the interview. They expect me to code vb, batch, WSH, etc on a white board....I've always been the one to reference a book or look for code on the internet.

Scripting knowledge is required, but It is only a small portion of a long list of required job responsibilities. I can put together a script with logic using reference points and put it together and tailor it our environment. Why reinvent the wheel?

I hate to stand there like an idiot and it's just a small portion of the technical interview process, all else of the process I'm comfortable because I know I'm well qualified for the job.

What can I do or say that could redirect/deflect my lack of expertise into a positive that would keep me from being out of the running?

[nick]

When's the interview? I'm in LA County, and I might have a couple of books on Windows scripting, since that's what you seem to be looking for. They cover VB/shell/WSH and PowerShell.

[nick]

Found the books on VB/WMI/ADSI and PowerShell. Shell is easy, you don't need a book for that.

Note to self: gotta clean up the clutter, some of the books are way obsolete.

[tools2teach]

When's the interview? I'm in LA County, and I might have a couple of books on Windows scripting, since that's what you seem to be looking for. They cover VB/shell/WSH and PowerShell.

Thanks for the offer. I have windows scripting books and it'is my main source of reference. Explaining and a coding on fresh white board is a different story.

[CapS]

I've had that kind of 'quiz' experience twice in my career. Flunked them both. I realized after a while that a company that wants to concentrate on what I *know* & can pull off the top of my head is not very wise. Companies that focussed on what I can do were not only a better fit, but had cultures that were closer to who I am.

YMMV, but I can only suggest you ask the question (do you want me for what kind of test I can pass, or for what I can do to contribute to your business?)

Oh, and I did find jobs shortly after those disappointments.

HTH

Cap

[smird]

I realized after a while that a company that wants to concentrate on what I *know* & can pull off the top of my head is not very wise. Companies that focussed on what I can do were not only a better fit, but had cultures that were closer to who I am.

This is true, the best IT guys may not know the answer right off the bat, but can figure it out in short order.

[lazyworm]

A closed book/closed notes test is not fair. That's not somebody going to work
as if he/she was doing the job for real. At my $dayjob, coding test is only
time and scope limited. The candidate has full internet access to look up
anything.

Anyways, if I were in your shoes, I'd do at least these 2 things during your
scripting tests --

1) talk out loud, let the interviewers know your thinking process.
2) do pseudo code/block diagram

This way, even if you flunk the actual script on the white board, you
only lose points on the language/syntax, not a goose egg.

[orchard]

Pick something to script that would be a typical project at the prospect company. Example like a script stop services, copy files, install application, then restart services.

Our request in interviews to do something similar is to see if you are comfortable discussing a subject in front of your peers, and to eliminate the prospects that don't understand how to solve a problem. We had too many people with offshore degrees that would just try to do tasks by trial and error based on what they found on Google.

[djleisure]

A closed book/closed notes test is not fair. That's not somebody going to work
as if he/she was doing the job for real. At my $dayjob, coding test is only
time and scope limited. The candidate has full internet access to look up
anything.

Anyways, if I were in your shoes, I'd do at least these 2 things during your
scripting tests --

1) talk out loud, let the interviewers know your thinking process.
2) do pseudo code/block diagram

This way, even if you flunk the actual script on the white board, you
only lose points on the language/syntax, not a goose egg.

I agree with everything here, especially the bolded parts. I've done this kind of interview before (taken and given) and the key part I was looking for was the thought process and those two points above will impart that just fine.

[loose_electron]

Be upfront about it -

"I will not get the syntax right, but here is what I would have the code do" and then outline the steps...

[den888]

Study at a high level and answer the question at a high level. Explain that you can and will research specifics as the situation arises.

[SwissFluCase]

I've had that kind of 'quiz' experience twice in my career. Flunked them both. I realized after a while that a company that wants to concentrate on what I *know* & can pull off the top of my head is not very wise. Companies that focussed on what I can do were not only a better fit, but had cultures that were closer to who I am.

YMMV, but I can only suggest you ask the question (do you want me for what kind of test I can pass, or for what I can do to contribute to your business?)

Oh, and I did find jobs shortly after those disappointments.

HTH

Cap

This only happened to me once. I "interviewed" at Lucas Arts once. I show up and wait about 30 minutes, then the office lady brings me into a room and hands me a thick stack of papers. She explains that it is a technical test. I look at it, and ask her when I will be meeting my would be manager. She says that depending on the test results it would be a few weeks. I handed her the test and told her that I was no longer interested in the position. She looked at me in total shock, so I explained to her that not only were they interviewing me, I was interviewing them. I had already found out what I needed to know.

Later that day my headhunter calls and tells me they did their due dilligence on me, and they wanted me to meet their team right away. Uh huh... I told him that I was not interested in working for a company that couldn't respect my time enough to at least let me meet and evaluate my would be manager. He told me that they can get away with their games because they were Lucas Arts. Sounded way too toxic for me... Well, it turns out I was right. Everyone I know who has worked there has been mistreated by that company in some way. I took another position and that was one of the best career moves in my life.

To get to the OP's issue... The moral of the story is, be wary of the company that wants you to jump through hoops. A good IT manager can figure out if you know your profession through casual conversation. The bigger concern are people skills, and again, A good IT manager will focus there. I evaluate technical people often, and not once have I needed to have any of them take a test.

I agree with lazyworm. Focus on the function on the script and what the language will do. The design is important. Exact syntax can be worked out later.

Best of luck, and I hope things work out for you!

Regards,


SwissFluCase

[weinerd]

If you don't know, it's okay to say you don't know, but try to work through it showing your thought process and reasoning. Ask for suggestions on where to go if you get stuck and say why you're stuck. Ask THEM a lot of questions. The more you ask, the less you have to answer...

As long as you don't come across as a dumbass, and don't come across as an arrogant prick if they ask something simple, you should do fine. Be accomodating, don't get frustrated. If you have 1-on-1 interviews later, you can always take a problem that you haven't solved, say you'd like to think on it a bit more and ask if you can talk about it in the 1-on-1...

Good luck!

[john.t.singh]

Google company and interview questions

Or just google interview questions regarding scripting and add key words

When I interviewed a bunch of those questions were actually on my technical interview

Ace what you do know and impress and try to bleed out the time
So they can't ask you things you do know.

Technical interviews are a real crap shoot. Sometimes you get lucky sometimes no matter what you know your ****ed

[sw99]

Don't worry about giving the "perfect" (or even "right") answer to the questions. Your goal is to show them that (a) you have the technical skills to do the job and (b) your personality and style will fit into their team.

As to answering questions on the whiteboard ... imagine you're working there and a production system goes down ... you'll grab a couple of co-workers, and white-board out the issue and a solution, right?

BTW don't laugh out loud when you realize their "difficult" questions are something someone with 5 years experience can/should be able to answer . And don't argue that the questions are stupid/meaningless/incorrect ... yep, you can make the point that it's not a true real-world situation, but play along with them ... they are the best questions they have ... and usually they are very proud of them