July 8, 2010 at 6:16 am
James Stover (7/2/2010)
Dan.Humphries (7/2/2010)
If you where a box of crayons what color would you be and why?I love when these types of questions get asked!
Can someone tell me how this tells them anything about me?
Periwinkle. I dunno; it's just the first color that popped into my head. Kind of a purpley-greyey-blue. Or better yet, #AAAAFF
Periwinkle = stupid answer for a stupid question 🙂
If I asked that question at an interview for an IT person (which would never happened), and they actually answered with an HTML color, I'd seriously consider hiring them. That's just the kind of geek I want.
--J
July 8, 2010 at 6:39 am
I actually did a lot of hiring in the past. It was at a fast-food restaurant, but I still learned a lot about people. I asked a host of questions, but in the end it really only came down to one question: What are your weaknesses? Of course even an honest person would down-play their weaknesses or choose something not work-related. Even better, they give you a real-life weakness that their trying to work on. But - and I learned this the hard way - a dishonest person will tell you that they have no weaknesses. At this point, you can't believe anything this person says to you. They are blowing smoke. Of course the rare person would tell me their weakness was that they didn't like to do dishes, or didn't deal well with people. Honesty isn't everything, I still didn't hire these people.
This is, of course, a little simplified because there's a huge difference between the hiring criteria of a fast-food restraurant and hiring a database developer or what-not, but the principal is the same. You need to know the core of what you are looking for, and you need to pose a few questions that really get down to the root of that. I was looking for honest people. Work ethic was also a virtue, and I asked a few questions to get to the core of that as well. In an interview for a SQL developer, I would probably ask about joins, because if you can understand the logic of a join you can probably understand most SQL. I might also introduce a few subjects the interviewer may not be familiar with, and guage his/her capacity for learning new ideas.
I will still definitely ask "What are your weaknesses?" in any interview I hold, and I think most people do. It's a great question, and it's answer is far more important than the precursory "What are your strengths?" The hard part, I've found, is interpretting the answer.
--J
July 8, 2010 at 7:08 am
Dan.Humphries (7/2/2010)
--------------------------------------------------------------------------------
If you where a box of crayons what color would you be and why?
--------------------------------------------------------------------------------
I'd be green and yellow of course because crayola makes some nice boxes, but if I was to be a coloring crayon what color would I be...dunno because that's just a silly question.
July 8, 2010 at 12:14 pm
Worked on a project with a guy that had BrainBench certificates plastered all over his office.
He couldn't even figure out how to make a sandwich, much less code anything. (And no, I'm not exagerating.)
Syntax-based testing is good for testing whether someone has memorized the syntax. In my experience, that has little correlation with productivity, which is the abilitty to reliably solve the problem correctly and quickly.
I find interview-style problems to solve much more useful. I find the questions the candidates ask to clarify the nature of the problem to solve very useful in predicting their ability level.
I don't care whether they know the syntax or not. I care whether they can solve the problem, how they go about solving the problem, and whether they know the limitations of the solution they provided under the time pressure of an interview. The syntax is generally easy to learn and pick up.
I've also learned that most managers haven't a clue in heck of how to interview a candidate. They will spend most of the interview time telling the candidate about the project they are being hired for or the company.
That's a total waste of time until you decide the candidate is worth hiring. 95% of all candidates for a senior position aren't worth hiring, so it's best to weed out the unsuitable ones quickly. Once you've found a good one, THEN spend your time getting them to want to join you. I've never found one that minded that we cut to the chase and verified that they actually knew their stuff. In fact, they seem to like the idea that we know our stuff enough to recognize and appreciate their skill.
In any technical language or toolkit, there are certain aspects that most people simply do not know unless they are really good at it. Those aspects are usually basic, core competencies with that language or toolkit. For example, in C or C++, memory allocation and pointers are key areas where most developers simply get it wrong. In SQL, it's set-based thinking vs. row-based thinking, types of joins, correct usage of correlated subqueries, constraints and business rule enforcement, and proper transaction design. For C#, it's inheritance vs composition, private/public/protected, interfaces vs classes, error handling with try/catch/finally and managing resources that the garbage collector doesn't handle.
For all technical environments: good coding standards, test design, and productive work habits are a must. Plus, of course, the soft skills that make for a good colleague.
July 8, 2010 at 2:59 pm
What color of crayon is interesting, if not a bit relevant, I'd probably think of an HTML color after the interview. Other than that it would depend, If my friend bought a new car I'd be green, if my girlfriend broke up with me I'd be blue, if she cheated I'd be red. Or maybe this should be 'select case mood:'
July 8, 2010 at 3:10 pm
Since my comment about the color question got a few laughs here is an article with questions that just scream "Please lie to me"
Enjoy the silly interview questions
http://www.businessweek.com/careers/content/sep2005/ca20050921_1099_ca009.htm
Dan
If only I could snap my figures and have all the correct indexes apear and the buffer clean and.... Start day dream here.
July 8, 2010 at 3:41 pm
Doh... I remember a silly interview question (and one used on a algebra test as extra credit.) "What is Captain James T. Kirk's middle name?" This was before the recent Star Trek movie. I've had that question at least twice. Once they followed it with "Star Trek or Star Wars?" and that was to figure out which side of the room I'd sit on.
July 9, 2010 at 10:48 am
I was placed on a gov't project once where things were REALLY bad.
I had been in this industry for over 20 years and thought I had seen or heard how bad things could get.
I was SO wrong about that. But I digress.
This appeared to be the interview process for the Oracle programmers they hired:
Interviewer: "Gosh, we need a really swell Oracle Forms programmer! Are you a really swell Oracle Forms programmer?"
Candidate: "Yes, I am."
Interviewer: "Swell! You're hired!"
It would have been nice if they could have known 3 out of the 6 letters in the word "Oracle", too. It would have been a major improvement in their skill set. 😛
I volunteered to help them screen candidates gratis. The mgr was a bit suspicious because he thought I might be trying to get more of his business by making the competition look bad. As if there was anything I could do to make the outhouse pit of staff skills they had supplied any more full of dung... 😀
I asked the first candidate a few questions and it became dirt obvious that this self-described top-notch Oracle Forms programmer didn't know the basic things he should know - or have a clue how to figure them out either.
Afterwards, the mgr asked me if I wasn't a bit hard on the fellow.
"Nope. Those are my standard interview questions for Oracle Forms. I'm on public record to that effect. Here's a copy of the technical journal they appeared in." 😎
We finally started getting some good ones in and drove out some of the complete incompetents that were also unwilling to learn.
The first rule of being a good manager is very simple:
"Do not hire the wrong people."
Most problems will never occur if you get this one right.
Productivity and quality standards among people who can actually get the job done vary by up to 20 to 1. Given that a large percentage of folks in IT development can't get the job done at all, I just can't understand why corporations don't try to do a better job in hiring and retaining good IT talent. A 10-1 programmer may cost twice as much in salary, but they'll produce 5 times as much value.
I've said for years that the best way to improve productivity on a typical 10 person team is to find and remove the 3 people who hold back progress. A typical team has 4 people moving forward, 3 moving backward, and 3 cleaning up the mess the backwards folks made. Removing the 3 backwards staff gives you the benefit of 7 staff for the cost of 7 staff. To get 7 forward progress staff by hiring more people, you have to hire another 6. 3 to move forward, 1 to move backwards, 1 to clean up the mess, and 1 to make up for the communication overhead of the larger team.
Viewing 8 posts - 46 through 52 (of 52 total)
You must be logged in to reply to this topic. Login to reply