|
|
meissnersd
Registered User
(3/27/01 10:49:56 am)
Reply | Edit | Del All effective technical interview questions
--------------------------------------------------------------------------------
What was the most effective technical interview question you ever had (sieved the good job applicant from the guy who inflated his resume)? What was the dumbest?
The best question I ever had was
"Given two dates, ranging from between 1 AD and today, write a function to return the number of days between the dates."
Basically, if the solution has a lot of if-then-else or switchs, it was inelegant. There were several elegant solutions, some using tables or conversions to neutral formats.
The dumbest I have heard had to be
"What was the biggest array you have every declared?"
________________________________________
Meissner Software Development, LLC
"Software development and project management services."
http://meissner.v0.net/resume-contract.htm
Jeremy Singer
Registered User
(3/27/01 10:56:01 am)
Reply | Edit | Del I would ask for more information
--------------------------------------------------------------------------------
The calendar, as we know it today, has changed a number of times. I would first want to know what the context of this function was.
If its just a meaningless excersise to see if you could code, that would be one thing.
If there was a real need (for example, to figure out astronomically what should have been visible for archeological or historical purposes) then more research should be done before going to code!
Tony Soprano SW Engineer
Registered User
(3/27/01 12:54:34 pm)
Reply | Edit | Del Appropriate technical interview response
--------------------------------------------------------------------------------
"Oh, puh-leeze! Just read my resume. I don't DO coding exercises in interviews."
Snark
Registered User
(3/27/01 1:18:11 pm)
Reply | Edit | Del Ask easy questions, they're already too hard
--------------------------------------------------------------------------------
>"Given two dates, ranging from between 1 AD and today, write a
>function to return the number of days between the dates."
Ich. That was a fair question back around 1977. I probably wrote that function several times, on several platforms, but only for dates after the switch to the Gregorian calendar in 1582. Today, I'd use a datediff routine or buy an extended function, if I had to go Gregorian. If you just want to see if they can use an array of twelve months, well, I hope that's not the level you need to filter at.
>The dumbest I have heard had to be
>"What was the biggest array you have every declared?"
Response: you mean, on purpose?
I almost hate to share it, but maybe it's past its prime now, or maybe not, but the most effective filter question I ever used was asked for C programmers, "What is the word NULL used for in C?" Knocked out about half the applicants.
The second best question I still use, is to ask people to describe the first three normal forms for relational databases. The only problem is, this is too tough, seems to knock out more than half of what look to be otherwise qualified applicants.
But then, I'm a hardass.
--
Besides, I almost don't care. I want to know if they have any conception of life cycle, development process, configuration control, and if they've ever actually coded and delivered anything all the way to production. Given good answers to those, I'd pretty much skip any and all specific technical questions.
Except that, again, these questions probably knock out 90% of applicants, in my recent experience.
Now, if I got an applicant pool of BS/MS Comp Sci graduates with five years experience, instead of trade tech and self-educated bargain candidates (and the odd H1B), my favorite questions might be otherwise.
Snark
meissnersd
Registered User
(3/27/01 4:24:13 pm)
Reply | Edit | Del %90<
--------------------------------------------------------------------------------
>"Oh, puh-leeze! Just read my resume. I don't DO
> coding exercises in interviews."
A few people have responded this way in interviews I have conducted. So I guess I would lose you. Oh well.
On the other hand, many, many more people, when asked about things they claim to know on their resume, can't answer the questions. They padded their resume. I am _glad_ I lost them.
>but only for dates after the switch to the Gregorian calendar in 1582
Most people don't know about the loss of most of October in 1585 or the rules for leap years that are divisible by 100 and 400. I usually don't mention them and just let people deal with leap years.
The test is not whether you happen to know calendar trivia, but whether you can come with a nice approach to a kind of yucky problem.
>"What is the word NULL used for in C?" Knocked out
> about half the applicants.
Really? yikes. it is even worse then I thought.
Though I tend to not ask questions about specific languages. Somebody who is really good will be able to learn any giving API or language in a fairly short time.
>Besides, I almost don't care. I want to know if they >have any conception of life cycle, development >process, configuration control, and if they've ever >actually coded and delivered anything all the way to >production.
For a team lead or higher, the applicant is required to know that. But for a developer, I don’t mind if they don't know what the waterfall model is.
>Now, if I got an applicant pool of BS/MS Comp Sci >graduates with five years experience, instead of >trade tech and self-educated bargain candidates (and >the odd H1B), my favorite questions might be >otherwise.
Two jobs ago I was doing the interviews for new hires for my group. We got a pile of applicants who had about 2 years experience in some web API or another, but could not answer really easy questions about a binary tree. Their whole career up to that point was writing glue code between one API to another. I feel sorry for these guys if economic times get tough.
dachshund1
Registered User
(3/27/01 4:43:25 pm)
Reply | Edit | Del put in front of a firing line
--------------------------------------------------------------------------------
(this was for a FTE position)
My worst was with a group who gave a test similar to yours. I had 15 minutes to write the code. THEN they marched in about 10 people who took pot shots at me! I had to write the code up on the board, and they fired questions at me.
After this started, it was clear that I didn't want to work there! My fantasy, years later when it didn't matter, is that in the middle of it I told them they had just proven that they were quite mean-spirited, and that they didn't deserve me. Bye bye... I wasn't quite that clever at the time, I just waited it out.
What a bunch of lunatics! They had the gall to show a candidate that they enjoyed being mean. Who'd want to work there??
My favorite question has been, "describe a difficult situation and how you resolved it." Gets the blood flowing, there are always plenty of examples to draw from.
When I was looking for FTE jobs, the other useless question was, "what do you see yourself doing in 5 years". What, do they like to watch you swallow sarcasm?
wylst
Registered User
(3/27/01 5:32:07 pm)
Reply | Edit | Del RE: binary trees
--------------------------------------------------------------------------------
Ugh.
Who uses binary trees anymore. Most data doesn't store well in a binary tree. Use a balanced tree/B-Tree.
These routines are build into many libraries. I probably couldn't code one up easily becauase I can't remember the algorithm. Could you code up a bubble sort algorithm? Why would you? I'm not up on which sort is quickest - some sort of insertion sort I imagine. But again, it's in the libraries and tools.
Rather than test theory, why not give them an algorithm and have them sketch a program. Odds are it won't be efficent. Efficient algorithms tend to be non-obvious.
I had a coding question given to me on an interview. Write a function that takes two integers and adds the sum of all numbers in between. Please _do_ use a loop rather than that funky formula. My response was: does argument sequence matter (f{1,2} ?= f{2,1}); should I include the endpoints (f{2,5} = 14 or 7); should f{-1,1} = 0; should f{0,0} = 0 leading to should f{5,5} = 0, 5 or 10; and what about overflow. Blew the interviewer away. He just wanted to make sure I could code a loop structure.
TRexx
Registered User
(3/27/01 5:36:06 pm)
Reply | Edit | Del Re: effective technical interview questions
--------------------------------------------------------------------------------
I typically interview IBM mainframe systems programmers so I always ask:
"What was the worst disaster you ever caused and how did you recover from it?"
The stupidest question I was ever asked was for a Y2K job that required wading through several hundred very old, undocumented BAL programs. The interviewer (who had written most of them) asked:
"What's your favorite 370 instruction?"
I thought for a minute and answered "EDMK (Edit and Mark) because without it you can't float the dollar sign when you print my check."
I've also had to sit through my share of group interviews -- one time there were 5 interviewers and two candidates in the same room. It turned into an exercise of "Name that Bit" as the interviewers probed my intimate knowledge of JES2 control blocks. I probably should have walked out, but I was young and wanted to show off how much I knew. HR was very upset when I declined the offer, especially when I told them what I thought about their interviewing techniques.
RMP
Registered User
(3/27/01 6:10:07 pm)
Reply | Edit | Del Just takes one line in Cobol
--------------------------------------------------------------------------------
Just takes one line in Cobol:
Compute Number-of-Days-Difference = Function Integer-Of-Date(Later-Date) - Function Integer-Of-Date(Earlier-Date)
OK, sure, depends on the declarations, and I'd have to double check whether the intrinsic functions can be used directly like that (I think Compute was necessary instead of Subtract), but that's the gist of it. Calendar differences aside, of course.
Robert M. Pritchett, President - RMP Consulting Partners LLC
People - Openings - Benefits - Fees - Acid Test - Umbrellas - Per Diems - IRS
Edited by: RMP at: 3/27/01 11:20:38 pm
Tony Soprano SW Engineer
Registered User
(3/27/01 9:53:58 pm)
Reply | Edit | Del lose me! lose me! I'm a loser!
--------------------------------------------------------------------------------
No, really. I don't do code tests in interviews. It is stupid. First of all, I don't write text oriented input output code. I write safety critical/ perfomance critical control software. That is something you take back to your desk and quietly spend hours thinking through. You spend time consulting reference manuals. You spend time experimenting with test code. You don't just throw stuff like that up on a whiteboard with a boss looking over your shoulder being annoyed at how long it is taking you, annoyed that you don't know this stuff right off the top of your head...
A few quick technical questions are meaningless in an interview. What is more important is verifying what kind of work this person has done in the past. Even if he/she IS the right person for the job, it is likely to take him or her weeks just to come up to speed. Even if I did write software for a particular bus or controller a few months ago, if I haven't looked at it for a few weeks, I probably don't remember a lot about it. But if I grab a book and spend a few minutes refreshing my memory I can get right back to it. Or something similar to it. So what makes you think you can get meaningful answers leading to accurate predictions in an interview setting? You can't.
I had this experience last year for the first time. The interviewer seemed to be more interested in showing his superiority than in determining if I could do the job. Write a complete concordance program in five minutes or less. Be serious. I am an embedded programmer - I write software on systems that do not have operating systems. I don't write text editors. I don't have the C++ Streams library memorized. I didn't get the job - and I am very glad I didn't.
Or even better, there was the interview where they wanted me to give a 15 minute technical presentation on the spur of the moment to a group of ten engineers. No preparation. Jeez-louise. I passed that one, by the way, but I refused to take the job they offered. They were too darn wacky for me to want to work with them.
jt
Unregistered User
(3/28/01 9:40:42 am)
Reply | Edit | Del No kidding
--------------------------------------------------------------------------------
No shinola, I do a google search and copy and test someone elses algorithm. I'm not a research monkey.
huh
Unregistered User
(3/28/01 11:28:38 am)
Reply | Edit | Del Re: effective technical interview questions
--------------------------------------------------------------------------------
The best technical question: the hiring manager showed be the requirements for a couple of the screens (web-based application) I would have to implement, then asked me what might be some of the technical issues we'd run into, and how I might implement them. We had an intelligent technical converstaion, he hired me.
The worst question by far is "what is the 3rd level of normalization, or the 4th, or whatever" In all the years I've developed applications for relational DBs, not once have I used (or seen someone use) these ideas in technical discussions or implementations.
Frankly, I'm surprised by some of the replies so far. The favorite questions seem to be one-liners regarding some specific technical detail. I figure good techies either know the answer or know where to find it (book, online, etc). The goal of a tech interview should be to find out if the person can carry on a techincal discussion, beit to describe a problem with their system or someone else's, plan the implementation of the next version, help someone else with their work, whatever. After all, that's mainly what you'll be doing with the person after you hire them.
What works: describe to the candidate the requirements for something that needs to be implemented. This must be something real, something you're planning to do, don't make it up. Ask the candidate to describe what the issues are, how they'd implement it. Then tell the candidate how you'd implement it, and ask them to compare your version with theirs.
What doesn't work: how many different data types are there in language X? What's the maximum size of character field in database Y? blah blah blah. My answer is always (even if I know the real answer): I don't know off the top of my head, I can look it up in the reference manual and get back to you.
Do you want to hire someone who cram-studied the books the night before, or someone who can do the job?
Lurker
Unregistered User
(3/28/01 12:24:49 pm)
Reply | Edit | Del Tech Questions I was asked yesterday
--------------------------------------------------------------------------------
Funny you should post this. I spent most of yesterday at an interview for an FTE job. I talked to four people, each one technical, but not all asked technical questions. Some were open-ended, on the level of "What have you done with COM"? "Have you used multiple threads in any app you've written?" "What is the feature you like most in Delphi? What is missing that you'd like to see?" (I answered "debugger" and "code profiler", respectively.
One guy went, very deliberately, into more depth. What were the significant differences you encountered between Oracle 7.3 and 8.0? (I struggled a bit, came up with PL/Java (which I've never used) and multiple blobs in a single table. I forget about embedded tables, because I've never used them.) What is the difference between a control's owner and its parent?
In the past I've had interviews that required me to write a recursive function or a SELECT with a HAVING clause (trivial exercises). I also had a know-it-all ask me about the layout in memory of VMTs.
I have mixed feelings about these quizzes. I _am_ representing (and pricing) myself as knowing Delphi and Oracle, and I don't think they are as obscure as the infamous "name the leaders of these countries" question posed to GW. But does knowing/not knowing these things mean I can/can't do the job? That's not clear.
Lurker
Unregistered User
(3/28/01 12:33:45 pm)
Reply | Edit | Del 3rd normal form
--------------------------------------------------------------------------------
"huh" wrote:
> The worst question by far is "what is the 3rd level
> of normalization, or the 4th, or whatever" In all
> the years I've developed applications for relational
> DBs, not once have I used (or seen someone use)
> these ideas in technical discussions or
> implementations.
My experience has been quite different. I don't care if you can't _define_ 3rd normal form (I would struggle myself). But the ability to normalize, and to understand why it's important, is crucial.
My last contract, the computer controlled multiple cameras. The original system spec specified 2 cameras, and the programmer implemented them as part of a single-record Configuration table, with fields Camera1_Name, Camera1_Location, Camera2_Name, etc. The system grew to support four cameras, then eight, and the programmer just added more fields.
One of my tasks was to permit 16 cameras. I looked at the existing schema, and refused to continue this nonsense.
This is the same programmer who took an unused ten-character field and used it to store eight boolean fields (one for each camera)...
meissnersd
Registered User
(3/28/01 1:59:39 pm)
Reply | Edit | Del reply to posts
--------------------------------------------------------------------------------
A lot of responses, but I will try to combine it into one post about:
Libraries and API
thinking on your feet
interview stress
---------------------------
>These routines are build into many libraries
and.....
> No shinola, I do a google search and copy and test
> someone elses algorithm. I'm not a research monkey.
I do not agree. Using libraries is a good way to develop rapidly. But what do you do if the problem you are trying solve isn't in the library? What do you do when the library is obsolete or not available on the system your are working on? Sorry to sound harsh but libraries are a tool, not a crutch you depend on.
> Just takes one line in Cobol:
>
>Compute Number-of-Days-Difference = Function Integer-> Of-Date(Later-Date) - Function Integer-Of-Date
>(Earlier-Date)
A good example of using a library to solve the problem well. It tells me you know Cobol well and that is a good sign (if you are working on a Cobol app) but I would still just ask a new question that Cobol did not have a precanned solution.
To me, it is not so import if you know a technology, since any library can be learned. Rather, can you solve tough problems.
>The favorite questions seem to be one-liners
> regarding some specific technical detail.
Some people think that having every little detail about an technology is important. I don't. I have seen too many technologies come, be popular a few years, and then go on the junk heap. I feel a strong technical person will be able to pick up what ever you throw at him.
>...various DB questions....
>But does knowing/not knowing these things mean I >can/can't do the job? That's not clear.
I agree. To me, those DB questions were too tied to a particular technology. What if next week the company decided to use a fabulous new DB that was not Oracle?
------------------------
> is something you take back to your desk and
> quietly spend hours thinking through.
I totally agree. The format of verbal interviews are a problem because they are typically really short. Some people think on their feet well, others are "deep" thinkers and come up will elegant solutions after mulling it over.
I really wish I could figure out how to tell difference between a deep thinker and somebody who can not solve the problem.
------------------------------
>The interviewer seemed to be more interested in
> showing his superiority than in determining
and....
> My worst was with a group who gave a test similar to
> yours. I had 15 minutes to write the code. THEN
> they marched in about 10 people who took pot shots
> at me!
Yes, I totally agree interviews are often needlessly hard and stressful. This is not the point at all.
One of the things I would like to figure out is how to run a (admittedly tough technical) interview, without coming across like I am out to "get" somebody. I know asking hard questions are stressful, but at the same time, I need to see how good an applicant is.
I would really like to figure out how test somebody hard, find the limit of their technical knowledge, and not intimidate them.
Snark
Registered User
(3/28/01 2:48:09 pm)
Reply | Edit | Del Yucky
--------------------------------------------------------------------------------
>The test is not whether you happen to know calendar trivia, but
>whether you can come with a nice approach to a kind of yucky
>problem.
Those are exactly the people I want to lose, the ones who will happily work on a problem they don't understand.
Between us, we can split up an applicant pool pretty quickly.
>Though I tend to not ask questions about specific languages.
> Somebody who is really good will be able to learn any giving API or
>language in a fairly short time.
Well, I agree with that, but I still ask language questions. Someone whose resume says they contributed a ton, but doesn't know a few basics about the language, I know I can tear up the resume as entirely bogus. If they don't know something obscure, they can learn it, though if they have too many gaps, I might prefer to hire somebody else, if available.
Snark
Snark
Registered User
(3/28/01 2:56:22 pm)
Reply | Edit | Del Technical questions for what job??????
--------------------------------------------------------------------------------
>I agree. To me, those DB questions were too tied to a particular
>technology. What if next week the company decided to use a fabulous
>new DB that was not Oracle?
Normalization is something that a lot of OO developers do not know, and they make a lot of mistakes thereby, waste a lot of time, blow a lot of projects.
It is hard to imagine any future database technology that does not build on relational -- certainly the OO databases that have ignored relational and SQL access, have gone nowhere, and it's for good reason.
You want to give people thought problems not tied to a language, and you don't expect them to know relational 3NF?
What sort of applications are you developing?????? What platform? What development methodology? Guess someone should have asked these things earlier.
But then, I guess you think none of that matters, am I right?
Snark
AshishL
Registered User
(3/28/01 3:43:38 pm)
Reply | Edit | Del Dumb questions...
--------------------------------------------------------------------------------
The interviewer looked at my resume' and asked my qualifications(MSCS) and then had the gall to ask me "how many bits in a byte?" - This was for a senior level C++ position too.....
meissnersd
Registered User
(3/28/01 3:50:14 pm)
Reply | Edit | Del I think we mostly agree
--------------------------------------------------------------------------------
>>The test is not whether you happen to know calendar trivia, but
>>whether you can come with a nice approach to a kind of yucky
>>problem.
>
>Those are exactly the people I want to lose, the
>ones who will happily work on a problem they don't >understand.
I find the applicants rarely ask a lot a questions about the problem. :-(
I chalk that up that up to the applicant not wanting to look dumb in the interview for asking a bunch of questions and feeling under time pressure. Basically, nerves.
Ironically, asking a lot of questions about the problem really impresses me. It is an important skill in a senior developer.
>Normalization is something that a lot of OO
> developers do not know, and they make a lot of
> mistakes thereby, waste a lot of time, blow a lot
> of projects
*I* did not criticize the normalization question. Seems like a good theory question. I was criticizing "What is the difference between Oracle 7.3 and 8.0?" To me, IMHO, that’s is question that is too tied to a particular technology. Maybe the interviewee used those systems, maybe not. It does not matter too much...
Snark, it seems you tend to ask "development process" questions. Those are very import, especially for team lead type positions. I ask those after the "problem solving" questions.
Snark
Registered User
(3/28/01 6:58:42 pm)
Reply | Edit | Del Well alrightee then
--------------------------------------------------------------------------------
>Snark, it seems you tend to ask "development process" questions.
>Those are very import, especially for team lead type positions. I
>ask those after the "problem solving" questions.
Only because I like to be disappointed.
Again, it may depend more on the job and the environment. I like to have one big, happy, sloppy, team, and that means we all have to understand process stuff. In the commercial/enterprise apps area that I usually inhabit, this matters. When I get even an inkling that candidates already are familiar with such issues, it calls for a ticker-tape parade. I guess I assume that anyone who can present me with an interesting resume and find their way to my office to talk, can solve problems on their own, I want to know how they'll fit into a team.
The kinds of problems I deal with seldom present any technical issues, assuming the developer has an average skill level and can punch the F1 key, or at least ask his neighbor to give him some guidance.
I had two junior devs on my last project. The guy would work for a few hours, then ask for help. Good. The gal would work for three days, until we wandered over to see what was holding things up, and foundnd she'd been stuck the entire time. Not good. I want talkers more than thinkers, or at least I'm further in that direction than a lot of people. I want people who panic when work isn't getting finished, not people who want to squeeze the last microsecond out of execution.
Technical skills are only as good as the use you can make of them. We all know the image of the know-it-all-nerd, who can't work on a team. I'll comprimise a fair way to get a person with great technical, problem solving skills, but I'd prefer average skills and great attitude, to the other way around. Maybe that's cuz I feel I can fill in on the problem solving side myself, those are only technical issues, while giving some nerd an actual personality is somewhat beyond what I can deliver under normal conditions.
Snark
Snark
Registered User
(3/28/01 7:01:43 pm)
Reply | Edit | Del Re: Dumb questions...
--------------------------------------------------------------------------------
I worked for a guy who didn't know how many bits in a hex digit. Maybe they needed to know!
Heck, I never believe anything I read, resume-wise, either. And certifications? Don't even get me going -- or at least start a separate thread!
I always started C/C++ interviews with a question once asked of me, "what is the semicolon used for in C?" It is a slightly tougher question than it looks like, the answer was different in Pascal. I think.
Per my other post, I wonder how many people the bits/byte question weeds out? You might just be surprised!
Snark
RMP
Registered User
(3/28/01 7:22:35 pm)
Reply | Edit | Del A byte is not always 8 bits
--------------------------------------------------------------------------------
On the CDC 6600 Central Processor(s), the data word was 60 bits, the address registers were 18 bits, the characters were 6 bit ASCII (upper case only), and yet I heard that a byte was considered 12 bits, which was the word size of the Peripheral Processors which handled I/O and interrupts.
Robert M. Pritchett, President - RMP Consulting Partners LLC
People - Openings - Benefits - Fees - Acid Test - Umbrellas - Per Diems - IRS
Dinosaur
Registered User
(3/28/01 11:10:42 pm)
Reply | Edit | Del Re: A byte is not always 8 bits
--------------------------------------------------------------------------------
And on GE 600, IBM 7094, Honeywell Level 66 and DPS, and I suppose others I haven't worked with, the byte is 9 bits, because the word lenght is 36 bits.
CDC has always been strange (or maybe I should refer to them in the past tense). The 1604 used a 48-bit double word. Integer values were 48 bit ones-complement binary (which gives two different "zeros", all zeros or all ones), floating point were (I think, but don't remember exactly) 12 bit exponent and 35 bit mantissa (leaving 1 bit for sign). Instructions were 24 bit with 15 bit address. The entrance to a subroutine was in the upper half of the word and the return address was stored in the lower half. And get this, instruction time varied between 4.7 and 7 milliseconds, i. e., or approx 143Hz! Compare that with 1GHz Pentiums!
Over what hill? I don't remember any hill!
Snark
Registered User
(3/28/01 11:38:12 pm)
Reply | Edit | Del 9 bits more
--------------------------------------------------------------------------------
>And on GE 600, IBM 7094, Honeywell Level 66 and DPS, and I suppose
>others I haven't worked with, the byte is 9 bits, because the word
>lenght is 36 bits.
Heavens to Murgatroyd, the DEC 10/20 series!
Snark
RMP
Registered User
(3/29/01 1:19:47 am)
Reply | Edit | Del And then there's MIX...
--------------------------------------------------------------------------------
MIX is Knuth's mythical machine used in our assembler language course at UT, I guess because the CDC 6600 and its Compass language were considered too weird. MIX had a 31 bit word, if I remember correctly - 1 sign bit and 5 6-bit bytes. And they thought the CDC 6600 was strange?
Robert M. Pritchett, President - RMP Consulting Partners LLC
People - Openings - Benefits - Fees - Acid Test - Umbrellas - Per Diems - IRS
David Cressey
Registered User
(3/29/01 7:48:19 am)
Reply | Edit | Del Re: A byte is not always 8 bits
--------------------------------------------------------------------------------
And on the DEC PDP-6, PDP-10, and DECsystem-10/20 series machines, a byte was described by a byte pointer, and one field of the byte pointer specified the byte size.
Popular byte sizes were 6 (for sixbit representation of ASCII), 7 (for ASCII codes), 8 (for compatibility with other processors) and 9 (for working internally with data). But a byte could be from 1 to 36 bits long.
When the PDP-6 was designed, the IBM 7094 would have been the maintream target, but by the time the PDP-10 became popular, the 360 was the center of IBM's offerings.
Regards,
David Cressey
Not all those who wander are lost.
Randy Given
Registered User
(3/29/01 8:01:52 am)
Reply | Edit | Del
Community Supporter
Tear Up Resume
--------------------------------------------------------------------------------
Sounds like most of us would tear up YOUR resume -- bad attitude.
Randy Given
Registered User
(3/29/01 8:05:18 am)
Reply | Edit | Del
Community Supporter
Not Lost Yet
--------------------------------------------------------------------------------
>I had this experience last year for the first time.
>The interviewer seemed to be more interested in showing
>his superiority than in determining if I could do the job.
I think you hit the nail on the head. What REALLY kills me is the type of person that asks this kind of technical question, trying to weed out applicants, and the interviewer is wrong! Most react poorly to that knowledge -- a double reason not to work for the interviewer.
Randy Given
Registered User
(3/29/01 8:07:10 am)
Reply | Edit | Del
Community Supporter
Re: Yucky
--------------------------------------------------------------------------------
>Those are exactly the people I want to lose, the ones
>who will happily work on a problem they don't understand.
Actually, that is the only way to learn something. How long since you stopped learning anything new?
Randy Given
Registered User
(3/29/01 8:13:14 am)
Reply | Edit | Del
Community Supporter
Re: 3rd normal form
--------------------------------------------------------------------------------
>My experience has been quite different. I don't care
>if you can't _define_ 3rd normal form (I would struggle
>myself). But the ability to normalize, and to understand
>why it's important, is crucial.
I agree about the latter. It is especially important that a person understands the CONCEPT, but may not know the proper names. The names have been different from my computer science course, database courses at Microsoft and Oracle, different companies I have worked for -- but the concept was the same.
Only some acamedician would be picky about the exact naming. Actually, the acamedician types are usually the only ones asking for coding tests (others would ask "how did you solve your last problem or a problem like this", trying to see how their mind works). Personally, I have worked for acamedician types and hope I never do so again.
Randy Given
Registered User
(3/29/01 8:14:25 am)
Reply | Edit | Del
Community Supporter
Re: And then there's MIX...
--------------------------------------------------------------------------------
Knuth's set is invaluable (I bought the whole set when it was reissued recently), but some of the MIX stuff was weird.
David Cressey
Registered User
(3/29/01 8:37:24 am)
Reply | Edit | Del Re: 3rd normal form
--------------------------------------------------------------------------------
Agreed.
Data Normalization is like structured programming. It's a useful design principle. (some would argue that it's an analysis principle).
Learning HOW to normalize is fairly easy (at least up to level 3). Learning WHEN to normalize is quite subtle. This is where experience, and awareness of the alternatives, is extremely valuable.
The folks who might mix up one level versus another, without reference to a textbook, are not in trouble. The people who never heard of normalization are in trouble.
And the people in the deep trouble, if you ask me, are of two kinds: the first kind says, "I studied all that normalization crap in school, and it's been utterly irrelevant in 10 years worth of work in the real world.
These people create a market niche in IT: cleaning up hopelessly screwed up database designs. The trouble with that niche is that it's very expensive, and the clients are already enraged at the start of the project.
The other type who are in deep trouble are the ones who say: I'll never design a star schema: hell, it isn't even normalized! This is a kid with a hammer, and all data look like a nail.
Regards,
David Cressey
Not all those who wander are lost.
Janet Ruhl
ezOP
(3/29/01 9:42:26 am)
Reply | Edit | Del
Community Supporter
Calendar Trivia and Systems Analysis
--------------------------------------------------------------------------------
The switch to the Gregorian calendar took place in 1582 ONLY in Catholic countries under the sway of the pope.
England (and America, which was still an English colony) retained the O.S. (old style) dates until 1752. Russia used old style dates until the Revolution.
I'm fascinated by the assumption by some posters here that the correct response to the question is to plunge into coding without doing systems analysis first!
The "trivia" you are advised to ignore, can be the issues that sink the code on system test.
I would have given 110% credit to any programmer who asked "what do you want me to do about calendar reform" before writing the routine.
huh
Unregistered User
(3/29/01 11:33:05 am)
Reply | Edit | Del Agreed too
--------------------------------------------------------------------------------
That's what I meant: when working with DB-based applications one must absolutely know the importance of normalization, and know when to normalize and when to "de-normalize", but one does not need to know the specifics of each level.
And yes, I was asked both questions at an interview. "What's a normalized database?" I explained that and also when full normalization may not be best (e.g. for many datamarts). Then the guy asks me "OK, so what's the 3rd level of normalization?", my answer: "I don't know, I don't care... Well, thanks for your time anyway, good luck."
meissnersd
Registered User
(3/29/01 12:25:39 pm)
Reply | Edit | Del trivia and system design
--------------------------------------------------------------------------------
>I would have given 110% credit to any programmer who
> asked "what do you want me to do about calendar
> reform" before writing the routine.
Of course you are correct. Very senior people will want to know all about the edge cases and more about the problem. That is what makes them senior.
So they score above 100% on that question :-)
Requirements and analysis is typically a senior position for just that reason.
On the other hand, there are plenty of people who have never heard of calendar reform and would not know it was an issue. They might be junior. The question is what kind of solution they come up with.
What I like about the calendar question is that it exposes what level the person is working on.
Senior level - does system analysis and good solution
coder - does an elegant solution
new grad - does an ugly or wrong solution
resume faker - "uhhhhhhh"
So the reason why I posted in the first place, does anyone else have questions that effectively find this out?
Hopefully, without the “nerves” problems already pointed out by several people
1) sounding like a hostile interrogator out to "get" the interviewee
2) it seem like there is too much time pressure
RMP
Registered User
(3/29/01 3:47:00 pm)
Reply | Edit | Del When to denormalize
--------------------------------------------------------------------------------
Learning HOW to normalize is fairly easy (at least up to level 3). Learning WHEN to normalize is quite subtle.
Right - I remember on one of my very first jobs fresh out of college, back in the 70's, my boss got me to help him denormalize a database in a payroll application generated using the SPEED 4GL for Basic on the Wang 2200. This didn't make sense to me until I saw that it reduced an 11 hour payroll run to 2 hours.
Robert M. Pritchett, President - RMP Consulting Partners LLC
People - Openings - Benefits - Fees - Acid Test - Umbrellas - Per Diems - IRS
Bitter Old Timer
Registered User
(3/29/01 4:02:20 pm)
Reply | Edit | Del MIX words
--------------------------------------------------------------------------------
The MIX word had a sign bit and 5 "bytes." The base was to be imagined as variable. Each byte could store values between zero and an upper limit, and that upper limit would be between 64 and 100. The upper limit was fixed in each "implementation" of MIX. A word could represent values between - (base^5) and + (base^5). All your bases are belong to us.
The simulators I have seen all used 64 as an upper limit. That way a MIX word will fit into a 32-bit integer, 30 data bits, 1 sign bit, one bit unused. That corresponds nicely to modern computers.
I suspect the purpose of this variability was to 1) make it easy to implement a MIX simulator in some of the decimal oriented computers that were used then, and 2) discourage a fixation on tricks one could play with arithmetic.
I have thought that one of the reasons for IBM's early successes was the recognition that data and text manipulation was to be the major use of computers, rather than just floating point computation. Their computers helped to make it easier to do that sort of programming, in the strange IBM notion of what easier meant.
Edited by: Bitter Old Timer at: 3/29/01 4:13:26 pm
Snark
Registered User
(3/29/01 9:30:42 pm)
Reply | Edit | Del Re: Yucky
--------------------------------------------------------------------------------
>Actually, that is the only way to learn something. How long since
>you stopped learning anything new?
It's been never since I stopped learning anything new.
Snark
mhp
Unregistered User
(5/16/01 8:24:04 pm)
Reply | Edit | Del Technical Interview Question site
--------------------------------------------------------------------------------
check out techinterview.editthispage.com
my favorite is the pirates puzzle:
five pirates have 100 gold coins. they have to divide up the loot. in order of seniority (suppose pirate 5 is most senior, pirate 1 is least senior), the most senior pirate proposes a distribution of the loot. they vote and if at least 50% accept the proposal, the loot is divided as proposed. otherwise the most senior pirate is executed, and they start over again with the next senior pirate. what solution does the most senior pirate propose? assume they are very intelligent and extremely greedy (and that they would prefer not to die).
solution at techinterview.editthispag...yReader$21
Snark
Registered User
(5/16/01 9:29:02 pm)
Reply | Edit | Del Somehow I doubt it
--------------------------------------------------------------------------------
* I doubt real pirates would act this way, at the least, a bunch of low-numbered pirates would see a bunch of high-numbered pirates killed off first, it would cost them nothing.
* I doubt all fogcreek employees figured this out in the interview
* I doubt this is a good use of interview time
* I doubt I'd want to work at fogcreek
* I bet the CEO of fogcreek keeps 98% of the profits for himself, that's the real reason for the question, to find the dweebs who will put up with it under some bogus mathematical explanation.
Snark
Jeremy Singer
Registered User
(5/17/01 7:28:00 am)
Reply | Edit | Del May you pick the binary fruit from the binary tree
--------------------------------------------------------------------------------
v
|
