Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««56789»»»

The IT Employee Benchmark Expand / Collapse
Author
Message
Posted Wednesday, April 10, 2013 1:05 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
djackson 22568 (4/10/2013)
SuperDBA-207096 (7/22/2008)
Good point! I always try to ask 'thinking' questions whenever I interview a candidate to get an idea of how they think.

Mark


Two of my favorite interviews:

1) Describe how you would program an elevator.

I spent the good part of an hour verbalizing how to do this, only to have him point out the flaws in every idea I had. As I answered each of his points, he found something else wrong.

He didn't care how I would program an elevator. He cared about whether I could think things through, and when presented with a flaw in my logic, how would I go about providing an alternative solution.

One of the most intelligent people I ever worked with or for.

2) This what I refer to as the "Star Trek Kobayashi Maru" interview.

I was presented with a scenario during a behavior based interview. The scenario was that I was functioning as a project manager, was one month from go live, on a 12-month project, and I just found out the project would be delayed by six months.

I pulled a James T Kirk response and rewrote the question! I explained how that simply wasn't possible. There is no way I can accept that I got into that situation. There is no excuse for being that far out of touch with reality. The interviewer smiled, and said "OK, I just assigned you as project manager to the project after firing the guy that was in charge..."

I enjoyed working for that company.


This is what many would term as a "deceptive" interview technique IMHO. Don't ask ithe interviewee how to "Program an elevator" when that was not what you wanted to know in the first place. That just confuses people. Interviewers need to concentrate on what they really want to know and then ask it in a forthcoming matter. Instead of trying to stump the interviewee or just to show people how smart or "cute" they are. Just my .02 cents.


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1440989
Posted Thursday, April 11, 2013 1:28 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Wednesday, July 30, 2014 8:53 AM
Points: 1,049, Visits: 3,003
TravisDBA (4/10/2013)
djackson 22568 (4/10/2013)
SuperDBA-207096 (7/22/2008)
Good point! I always try to ask 'thinking' questions whenever I interview a candidate to get an idea of how they think.

Mark


Two of my favorite interviews:

1) Describe how you would program an elevator.

I spent the good part of an hour verbalizing how to do this, only to have him point out the flaws in every idea I had. As I answered each of his points, he found something else wrong.

He didn't care how I would program an elevator. He cared about whether I could think things through, and when presented with a flaw in my logic, how would I go about providing an alternative solution.

One of the most intelligent people I ever worked with or for.

2) This what I refer to as the "Star Trek Kobayashi Maru" interview.

I was presented with a scenario during a behavior based interview. The scenario was that I was functioning as a project manager, was one month from go live, on a 12-month project, and I just found out the project would be delayed by six months.

I pulled a James T Kirk response and rewrote the question! I explained how that simply wasn't possible. There is no way I can accept that I got into that situation. There is no excuse for being that far out of touch with reality. The interviewer smiled, and said "OK, I just assigned you as project manager to the project after firing the guy that was in charge..."

I enjoyed working for that company.


This is what many would term as a "deceptive" interview technique IMHO. Don't ask ithe interviewee how to "Program an elevator" when that was not what you wanted to know in the first place. That just confuses people. Interviewers need to concentrate on what they really want to know and then ask it in a forthcoming matter. Instead of trying to stump the interviewee or just to show people how smart or "cute" they are. Just my .02 cents.

Deceptive, perhaps.

However, remember that DJackson got both those jobs. That implies that the interviewer found out what they wanted, and that DJackson liked what the technique (and interviewer) told him about the respective companies. That's a successful interview in anyone's book.

What it does say, though, is that the companies DJackson worked for are not ones you'd have been comfortable in. That's also good, because if you'd gone to those interviews you'd have known early on and not wasted your time in a job that wasn't for you. Again, a successful interview.


Semper in excretia, sumus solum profundum variat
Post #1441133
Posted Thursday, April 11, 2013 6:14 AM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: 2 days ago @ 2:25 PM
Points: 24, Visits: 95
@majorbloodnock
Concerning your remark from July 2008 about CS degreed folks having a better grasp of DB theory.

In my experience that has not been necessarily the case. Even though there is a lot of valuable information in "Book Larnin' ", I've found that these people have a tendency to create the most insanely complex databases with data stored in the fifth Normal form and five part primary keys and the worse in my opinion, manually-entered data used as the primary key.

I don't know how many times I've seen people traisping all through a database tracking down foreign keys to fix fat-fingered data. Whereas if that had been made a unique key with a generated primary key it would have only needed to be changed in one location.

On each occasion, the db designer reported that was what he or she had learned in college. So I've always had a biased viewpoint of college DB courses. I much prefer someone with experience with a knowlege of what not to do and why.

Post #1441202
Posted Thursday, April 11, 2013 7:06 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Wednesday, July 30, 2014 8:53 AM
Points: 1,049, Visits: 3,003
ejoell 66477 (4/11/2013)
@majorbloodnock
Concerning your remark from July 2008 about CS degreed folks having a better grasp of DB theory.

In my experience that has not been necessarily the case. Even though there is a lot of valuable information in "Book Larnin' ", I've found that these people have a tendency to create the most insanely complex databases with data stored in the fifth Normal form and five part primary keys and the worse in my opinion, manually-entered data used as the primary key.

I don't know how many times I've seen people traisping all through a database tracking down foreign keys to fix fat-fingered data. Whereas if that had been made a unique key with a generated primary key it would have only needed to be changed in one location.

On each occasion, the db designer reported that was what he or she had learned in college. So I've always had a biased viewpoint of college DB courses. I much prefer someone with experience with a knowlege of what not to do and why.


Sorry, but I think you'll find it was PollockK who wrote that one - the post just before my one. Mind you, it was not far off 5 years ago, so I had to go searching to refresh my memory.....

Personally, I've seen both heavily over- and under-normalised databases and most of the related problems actually come to pass. I obviously try to find the happy medium, sometimes even getting it right. For the record, I don't have an IT related degree.


Semper in excretia, sumus solum profundum variat
Post #1441226
Posted Thursday, April 11, 2013 7:26 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 7:54 PM
Points: 23,227, Visits: 31,921
ejoell 66477 (4/11/2013)
@majorbloodnock
Concerning your remark from July 2008 about CS degreed folks having a better grasp of DB theory.

In my experience that has not been necessarily the case. Even though there is a lot of valuable information in "Book Larnin' ", I've found that these people have a tendency to create the most insanely complex databases with data stored in the fifth Normal form and five part primary keys and the worse in my opinion, manually-entered data used as the primary key.

I don't know how many times I've seen people traisping all through a database tracking down foreign keys to fix fat-fingered data. Whereas if that had been made a unique key with a generated primary key it would have only needed to be changed in one location.

On each occasion, the db designer reported that was what he or she had learned in college. So I've always had a biased viewpoint of college DB courses. I much prefer someone with experience with a knowlege of what not to do and why.



Well, they obviously had an ivory tower professor teaching the class. My classes on DB design went to 6th normal form (would probably have problems today trying to get to 4th or 5th). Had a good professor as he said we would probably never implement a database at this level of normalization. He was pragmatic, as he said normalize as far as you need to then denormalize where it makes sense. This process helps you to understand the trade offs necessary in other areas to ensure that the data is protected.

How was it some else put it, oh yea, "Normalize until it hurts, denormalize until it works."




Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #1441239
Posted Thursday, April 11, 2013 7:45 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
majorbloodnock (4/11/2013)
TravisDBA (4/10/2013)
djackson 22568 (4/10/2013)
SuperDBA-207096 (7/22/2008)
Good point! I always try to ask 'thinking' questions whenever I interview a candidate to get an idea of how they think.

Mark


Two of my favorite interviews:

1) Describe how you would program an elevator.

I spent the good part of an hour verbalizing how to do this, only to have him point out the flaws in every idea I had. As I answered each of his points, he found something else wrong.

He didn't care how I would program an elevator. He cared about whether I could think things through, and when presented with a flaw in my logic, how would I go about providing an alternative solution.

One of the most intelligent people I ever worked with or for.

2) This what I refer to as the "Star Trek Kobayashi Maru" interview.

I was presented with a scenario during a behavior based interview. The scenario was that I was functioning as a project manager, was one month from go live, on a 12-month project, and I just found out the project would be delayed by six months.

I pulled a James T Kirk response and rewrote the question! I explained how that simply wasn't possible. There is no way I can accept that I got into that situation. There is no excuse for being that far out of touch with reality. The interviewer smiled, and said "OK, I just assigned you as project manager to the project after firing the guy that was in charge..."

I enjoyed working for that company.


This is what many would term as a "deceptive" interview technique IMHO. Don't ask ithe interviewee how to "Program an elevator" when that was not what you wanted to know in the first place. That just confuses people. Interviewers need to concentrate on what they really want to know and then ask it in a forthcoming matter. Instead of trying to stump the interviewee or just to show people how smart or "cute" they are. Just my .02 cents.

Deceptive, perhaps.

However, remember that DJackson got both those jobs. That implies that the interviewer found out what they wanted, and that DJackson liked what the technique (and interviewer) told him about the respective companies. That's a successful interview in anyone's book.

What it does say, though, is that the companies DJackson worked for are not ones you'd have been comfortable in. That's also good, because if you'd gone to those interviews you'd have known early on and not wasted your time in a job that wasn't for you. Again, a successful interview.


Major,

Whether he got the job or not is not really the point. What Equal Opportunity Employers today can ask or not ask in job interviews is tightly regulated now by the law, and I say it is about time. Deceptive questions like this have eliminated minorites in the past and are now considered a deceptive, discrimatory, and illegal practice by many.:)


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1441255
Posted Thursday, April 11, 2013 7:58 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 7:54 PM
Points: 23,227, Visits: 31,921
TravisDBA (4/11/2013)
majorbloodnock (4/11/2013)
TravisDBA (4/10/2013)
djackson 22568 (4/10/2013)
SuperDBA-207096 (7/22/2008)
Good point! I always try to ask 'thinking' questions whenever I interview a candidate to get an idea of how they think.

Mark


Two of my favorite interviews:

1) Describe how you would program an elevator.

I spent the good part of an hour verbalizing how to do this, only to have him point out the flaws in every idea I had. As I answered each of his points, he found something else wrong.

He didn't care how I would program an elevator. He cared about whether I could think things through, and when presented with a flaw in my logic, how would I go about providing an alternative solution.

One of the most intelligent people I ever worked with or for.

2) This what I refer to as the "Star Trek Kobayashi Maru" interview.

I was presented with a scenario during a behavior based interview. The scenario was that I was functioning as a project manager, was one month from go live, on a 12-month project, and I just found out the project would be delayed by six months.

I pulled a James T Kirk response and rewrote the question! I explained how that simply wasn't possible. There is no way I can accept that I got into that situation. There is no excuse for being that far out of touch with reality. The interviewer smiled, and said "OK, I just assigned you as project manager to the project after firing the guy that was in charge..."

I enjoyed working for that company.


This is what many would term as a "deceptive" interview technique IMHO. Don't ask ithe interviewee how to "Program an elevator" when that was not what you wanted to know in the first place. That just confuses people. Interviewers need to concentrate on what they really want to know and then ask it in a forthcoming matter. Instead of trying to stump the interviewee or just to show people how smart or "cute" they are. Just my .02 cents.

Deceptive, perhaps.

However, remember that DJackson got both those jobs. That implies that the interviewer found out what they wanted, and that DJackson liked what the technique (and interviewer) told him about the respective companies. That's a successful interview in anyone's book.

What it does say, though, is that the companies DJackson worked for are not ones you'd have been comfortable in. That's also good, because if you'd gone to those interviews you'd have known early on and not wasted your time in a job that wasn't for you. Again, a successful interview.


Major,

Whether he got the job or not is not really the point. What Equal Opportunity Employers today can ask or not ask in job interviews is tightly regulated now by the law, and I say it is about time. Deceptive questions like this have eliminated minorites in the past and are now considered a deceptive, discrimatory, and illegal practice by many.:)


Please elucidate on how the questions asked are deceptive?



Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #1441263
Posted Thursday, April 11, 2013 8:05 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Yesterday @ 10:43 AM
Points: 479, Visits: 786
Damus (7/22/2008)
jay holovacs (7/22/2008)
Wayne West (7/22/2008)
I'm sorry, but I'm not really seeing anything new here. "Degrees and certifications are no indicator of quality." "We want team players." "We want flexible people." If they believe that degrees and certifications are not an indicator of quality, then tell their HR departments to stop asking for them. ....


Alas, requiring certs is another part of CYA, especially in the hiring world where claims of bias or discrimination in hiring can be a legal minefield. It passes off much of the work of evaluating a prospect to a third party.

IT knowledge does not exist in a vacuum. More often than not, the IT skills you refer to are reflected in other aspects of a person's life and interests. Is this the type of person whose first instinct is to pick up a tool when something goes wrong around the house or the car? Is it the kind of person who is constantly reading, who is trying to improve their personal space (house, car, garden) through tinkering? Or are they completely passive, getting through, or wanting everything to be pre-packaged for them?


I have some colleagues who do not own a computer at home. When asked why? they answer, they have no need for it.

I do not believe in a programmer without a computer at home.
I do not believe in a programmer who does not tinker with programs at home.
I do not believe in a programmer who does not play computer games.


I don't agree with you 100%, maybe 95%. That said, I have twice as many PCs at home as I do people living there! For video games, I have never owned a Sega Genesis, but have owned everything else. Nook Tablets, kindles, iPads, iPhones, iPods, well I don't have a iPad Mini yet! As to the part you quoted above about picking up a tool, the only thing I don't do on my car is transmission repairs. The only thing I don't do on my house is roofing (too steep) and some furnace repairs. There is not a single area of repair on my home that I have not done at some point, roofing and heating simply being things I chose to no longer do.

Where I disagree is that I do respect that people need to step away from work. I have no programmers that were excellent, but that chose to not program at home. Generally I think you are correct, but there are some limited exceptions.


Dave
Post #1441266
Posted Thursday, April 11, 2013 8:10 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
Asking an obvious question and expecting a different type of answer. Just read what he posted.

"Describe how you would program an elevator.

I spent the good part of an hour verbalizing how to do this, only to have him point out the flaws in every idea I had. As I answered each of his points, he found something else wrong.

He didn't care how I would program an elevator. "


If he really didn't care how he would program an elevator, he should not have ask the question. The question is deceptive and designed to trick the interviewee. Trick questions in a interview are strictly forbidden in working environments governed by EOE. If the interviewer actually would have told him that (which I am not sure he did)then the interviewee could have grounds for a lawsuit. Particularly if the interviewee was a minority. It's not the first itmie this has happened, believe me..


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1441268
Posted Thursday, April 11, 2013 8:19 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 1:44 PM
Points: 12,904, Visits: 31,978
i'd have to see an example of what would actually be prohibited where you said

"Trick questions in a interview are strictly forbidden in working environments governed by EOE"

that doesn't sound like it could be prohibited by Equal Opportunity laws; ANY question could be litigated as a trick question, including questions about figuring out situations with divide by zero errors.,

that seems to me relevant especially where it would conflict with an evaluation of an interviewee's skillset.


Lowell

--There is no spoon, and there's no default ORDER BY in sql server either.
Actually, Common Sense is so rare, it should be considered a Superpower. --my son
Post #1441274
« Prev Topic | Next Topic »

Add to briefcase «««56789»»»

Permissions Expand / Collapse