Interview questions?
-
This question has only one point: you may check if programmer starts coding right away or spends 30 second thinking about the solution. Very important aspect, IMHO. Tomasz Sowinski -- http://www.shooltz.com
To some its a six-pack, to me it's a support group
Tomasz Sowinski wrote: This question has only one point: you may check if programmer starts coding right away or spends 30 second thinking about the solution. Very important aspect, IMHO. Yes, I agree that it's important to hire someone that can get started right away. But why not do it with a practical question? As I implied, unless the candidate has had recent exposure to "cool" math algorithms, he just isn't going to know the answer to this one. (I didn't know it before and heck, I've already forgotten it. :-)) But something like, "How do you make a copy of an array?", is IMHO a better way to measure a candidate's readiness for the job. And by the way, spending an extra 30 seconds (or minutes) thinking about how to solve a problem is usually OK if it yields maintainable code that does the job well, IMHO. Plus, if you're getting payed by the hour, even better ;). Regards, Alvaro Insanity: doing the same thing over and over again and expecting different results. - Albert Einstein
-
Really you're not allowed to ask for code? I've been to interviews before and had to write some, admittedly it was VB (no flame follow-ups please :) but I still wrote it. What's the reasoning behind it? Some kind of copyright thing? What about asking for flow-chart type stuff? -- Paul "I need the secure packaging of Jockeys. My boys need a house!" - Kramer, in "The Chinese Woman" episode of Seinfeld MS Messenger: paul@oobaloo.co.uk Sonork: 100.22446
Yes - It is surprising, but it turns out that unless your tests can be defended in court, avoid it altogether. For more detail : read up on (Supreme Court Griggs Vs Duke Power) http://www.employeeselect.com/testLegal.htm[^] Some more rules (if u wanna stay out of trouble) 1. Avoid problem solving questions that are not standardized.(not asked to every potential candidate ) (eg. "What is the command in CVS to create a branch ?" to one candidate and "What is CVS ?" to another one). This is a clear example of aribitrary testing. The employee has the right to sue the company under these circumstances. 2. No role-playing questions (eg. Sell me that chair) 3. No questions at all about personal stuff, hobbies, lifestyle, general attitudes. 4. Situational questions : (What would u do if you were at a customer site and the product refused to print ) Of course,most interviewees wont bother, but only takes one pissed off employee to really get ur company in a legal mess :omg: I am frankly surprised so many in CP are encouraging tests in interviews. Any comments ? I would like to hear your views.. Vivek
-
This question has only one point: you may check if programmer starts coding right away or spends 30 second thinking about the solution. Very important aspect, IMHO. Tomasz Sowinski -- http://www.shooltz.com
To some its a six-pack, to me it's a support group
Just for the record, I think it is an excellent question !! It took me more than 30secs to realise the solution though :-( as it appeared way too easy. Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
Hi, I'm giving an interview (2nd round) to a potential VC/C/C++ software engineer (4 years experience) later this afternoon. What sort of questions should I ask? Do you have some good sample technical questions you can share? I'd kind of like to test this guy's technical knowledge and see how he handles both easy and difficult questions... Thanks! Chris
Aside from the technical questions (which I often find misleading, I much prefer to get him to write some actual code). I find the best way to judge a person's technical knowledge is to get him to talk about the projects he has worked on in the past. Find out what he's done and ask about the reasons he did things the way he did. Michael Programming is great. First they pay you to introduce bugs into software. Then they pay you to remove them again.
-
Maximilien wrote: Remember, your job is to hire someone, not break him! Agreed. Also, if you are going to be working with the guy, the most important thing is to decide if you and your co-workers will like him. Andy Cowenhoven
Andy Cowenhoven wrote: Also, if you are going to be working with the guy, the most important thing is to decide if you and your co-workers will like him. This is asking for trouble in the US. You are not allowed to test a candidate for *general likeability* (Griggs vs Duke Power) - see my other post below. Yes, as an unspoken rule - you may only select candidates u feel comforatble with. The candidate can sue the company big-time if you explicity test him or her for likeability or other non job-related criteria. Therefore, avoid all questions that may be construed to be non-job related, such as: 1) Do you like beer ? we have a beer party every Friday. 2) I hope u like to play foosball, we have a league in the office. etc,etc u get the idea Vivek
-
Tomasz Sowinski wrote: This question has only one point: you may check if programmer starts coding right away or spends 30 second thinking about the solution. Very important aspect, IMHO. Yes, I agree that it's important to hire someone that can get started right away. But why not do it with a practical question? As I implied, unless the candidate has had recent exposure to "cool" math algorithms, he just isn't going to know the answer to this one. (I didn't know it before and heck, I've already forgotten it. :-)) But something like, "How do you make a copy of an array?", is IMHO a better way to measure a candidate's readiness for the job. And by the way, spending an extra 30 seconds (or minutes) thinking about how to solve a problem is usually OK if it yields maintainable code that does the job well, IMHO. Plus, if you're getting payed by the hour, even better ;). Regards, Alvaro Insanity: doing the same thing over and over again and expecting different results. - Albert Einstein
Being able to solve the problem as Tomasz suggested with an algorithm shows how the candidates mind works. I don't think he is suggesting that is the only factor for determining who get's the job. When I first started programming, 20 ++ yrs ago we always searched for algorithms before trying structured methods. There were more advantages then, but one main advantage remains, well written algorithms don't fail like most structures do thus less bugs. Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
Aside from the technical questions (which I often find misleading, I much prefer to get him to write some actual code). I find the best way to judge a person's technical knowledge is to get him to talk about the projects he has worked on in the past. Find out what he's done and ask about the reasons he did things the way he did. Michael Programming is great. First they pay you to introduce bugs into software. Then they pay you to remove them again.
Michael P Butler wrote: (which I often find misleading, I much prefer to get him to write some actual code). It would be ok , if the test were standardized or at least had a consistent level of difficulty. Isnt this arbitrary ? What if you asked one person to write a "hello world" and another person to write a "recursive loop" ? This may happen becuase there may be different interviewers. - V
-
Tomasz Sowinski wrote: This question has only one point: you may check if programmer starts coding right away or spends 30 second thinking about the solution. Very important aspect, IMHO. Yes, I agree that it's important to hire someone that can get started right away. But why not do it with a practical question? As I implied, unless the candidate has had recent exposure to "cool" math algorithms, he just isn't going to know the answer to this one. (I didn't know it before and heck, I've already forgotten it. :-)) But something like, "How do you make a copy of an array?", is IMHO a better way to measure a candidate's readiness for the job. And by the way, spending an extra 30 seconds (or minutes) thinking about how to solve a problem is usually OK if it yields maintainable code that does the job well, IMHO. Plus, if you're getting payed by the hour, even better ;). Regards, Alvaro Insanity: doing the same thing over and over again and expecting different results. - Albert Einstein
Alvaro Mendez wrote: As I implied, unless the candidate has had recent exposure to "cool" math algorithms, he just isn't going to know the answer to this one First of all, the formula for sum(1..n) is hardly 'cool' - it's firetrucking basic one. Secondly, you don't need to remember the formula, because you can easily derive it yourself. Just notice that you can add 1 to n, 2 to (n-1), 3 to (n-2) etc... Tomasz Sowinski -- http://www.shooltz.com
To some its a six-pack, to me it's a support group
-
Tomasz Sowinski wrote: Surely it has nothing to do with javascript Hardy har har. Tomasz Sowinski wrote: I'm not sure what do you mean by 'everyday programming' The kind of programming that creates apps that users use to get their job done better. I fully agree math is important if you are working for Intel or doing scientific applications, but how many of us actually do that kind of programming? Most of us are data-managers. We make systems which allow data input, data output, data processing and data transformation. Not much else. So far I have had very little need for math beyond adding. Where there are calculations to do, they are hardly complex and are understandable because instead of
x2 * 2y / cos(50)we have((warrantPrice * totalWarrants) / strikePrice) - (sharePrice2)or something. All in all though the calculations are (while critical) a very small part of the code you write.Paul Watson
Bluegrass
Cape Town, South AfricaPaul Watson wrote: All in all though the calculations are (while critical) a very small part of the code you write Hey Something we agree on!!!! We did a survey ( line count type ) of our apps which are mainly insurance type applications ( calculating rates etc.. ) and the actual percentage of calulation code vs UI and printing was 7% thats all 7 lines out of 100. And a lot of that was stuff to calculate the strange and murkey underwriting logic - not so much number crunching. Richard We are called the nation of inventors. And we are. We could still claim that title and wear its loftiest honors if we had stopped with the first thing we ever invented, which was human liberty. Mark Twain- Foreign Critics speech, 1890
-
Tomasz Sowinski wrote: Surely it has nothing to do with javascript Hardy har har. Tomasz Sowinski wrote: I'm not sure what do you mean by 'everyday programming' The kind of programming that creates apps that users use to get their job done better. I fully agree math is important if you are working for Intel or doing scientific applications, but how many of us actually do that kind of programming? Most of us are data-managers. We make systems which allow data input, data output, data processing and data transformation. Not much else. So far I have had very little need for math beyond adding. Where there are calculations to do, they are hardly complex and are understandable because instead of
x2 * 2y / cos(50)we have((warrantPrice * totalWarrants) / strikePrice) - (sharePrice2)or something. All in all though the calculations are (while critical) a very small part of the code you write.Paul Watson
Bluegrass
Cape Town, South AfricaPaul Watson wrote: but how many of us actually do that kind of programming? me! Paul Watson wrote: Most of us are data-managers. i absolutely f'in hate data pushing. Paul Watson wrote: All in all though the calculations are (while critical) a very small part of the code you write. yeah, in most places that's probably true. but not in my house! :) -c
"Kate said / The flowers of intolerance and hatred / Are blooimg kind of early this year / Someone's been watering them. -- Robyn Hitchcock, Devil's Radio
-
Maximilien wrote: second round ? does that mean he was already interviewed ? if so I would assume that all the technical questions were already asked and answered, and that he answered correctly ! Actually it could be quite the opposite, many times companies have a front ( I like to call them HR departments) where they have associates try to run you through the ringer with some techno-babble (that of which they don't understand) and if they like you, you progress to stage two; speaking with someone who is in the IT department :cool:. My suggestion is keep in mind that there are always many ways to do the similar task. Given Tomasz question at the top, he may initially list off a for loop where you use a simple math algorithm. Then again you probably don't know everything and at sometime he may actually shed some light as to a more efficient way to do another process than you. Don't initially strike them for good because they didn't answer a question exactly as you thought was *best*. Nick Parker
Nick Parker wrote: ( I like to call them HR departments) IMHO: I think they are scum, and often cause the wrong people to see the IT departments. Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
Being able to solve the problem as Tomasz suggested with an algorithm shows how the candidates mind works. I don't think he is suggesting that is the only factor for determining who get's the job. When I first started programming, 20 ++ yrs ago we always searched for algorithms before trying structured methods. There were more advantages then, but one main advantage remains, well written algorithms don't fail like most structures do thus less bugs. Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
Colin^Davies wrote: Being able to solve the problem as Tomasz suggested with an algorithm shows how the candidates mind works. Fair enough, but what ends up happening is one of these things: 1. The candidate knows the answer cold, either because his name is Tomasz or because he read (and memorized) Tomasz's response above. :-) 2. The candidate spends a few seconds (or minutes) trying to figure out the algorithm. So much for that theory of him being able to jump in and start coding right away. :-) 3. The candidate gets nervous and comes up with a not-so-cool solution, like a loop or recursive function. 4. The candidate is a dope and gives an incorrect or stupid answer. Insanity: doing the same thing over and over again and expecting different results. - Albert Einstein
-
i know some good programmers who use the mouse for copy/paste. i don't understand it, at all. i have the same feeling about them that i do about people who enable every toolbar an app offers, leaving them all of two inches of actual workspace. then there are the people who enable/disable breakpoints or start builds, or any number of things from the toolbar (just use the keyboard!) it infuriates me. (have i insulted everyone here yet? :) ) -c
"Kate said / The flowers of intolerance and hatred / Are blooimg kind of early this year / Someone's been watering them. -- Robyn Hitchcock, Devil's Radio
I have two modes: 1. Keyboard - used when editing code 2. Mouse - used when debugging code So I basically use the mouse to click on the buttons for stepping through the code and setting breakpoints, etc. But if I'm just writing code, I make full use of the keyboard shortcuts -- Ctrl+S being my favorite one. :-) Regards, Alvaro Insanity: doing the same thing over and over again and expecting different results. - Albert Einstein
-
i know some good programmers who use the mouse for copy/paste. i don't understand it, at all. i have the same feeling about them that i do about people who enable every toolbar an app offers, leaving them all of two inches of actual workspace. then there are the people who enable/disable breakpoints or start builds, or any number of things from the toolbar (just use the keyboard!) it infuriates me. (have i insulted everyone here yet? :) ) -c
"Kate said / The flowers of intolerance and hatred / Are blooimg kind of early this year / Someone's been watering them. -- Robyn Hitchcock, Devil's Radio
I once saw a programmer (yes, a programmer) do the following: Using the mouse: 1. click on a word 2. highlight the word 3. pull down the Edit menu 4. click Cut 5. click on the new position 6. pull down the Edit menu 7. click Paste Guess how far he needed to move the word. Marc
-
Hi, I'm giving an interview (2nd round) to a potential VC/C/C++ software engineer (4 years experience) later this afternoon. What sort of questions should I ask? Do you have some good sample technical questions you can share? I'd kind of like to test this guy's technical knowledge and see how he handles both easy and difficult questions... Thanks! Chris
-
I once saw a programmer (yes, a programmer) do the following: Using the mouse: 1. click on a word 2. highlight the word 3. pull down the Edit menu 4. click Cut 5. click on the new position 6. pull down the Edit menu 7. click Paste Guess how far he needed to move the word. Marc
:wtf: I wish I had eye implants so could go even faster. That would be so cool to be able to edit code by looking and thinking. Of course by the time we get that far, editing code will be the old way. Todd Smith
-
:wtf: I wish I had eye implants so could go even faster. That would be so cool to be able to edit code by looking and thinking. Of course by the time we get that far, editing code will be the old way. Todd Smith
I don't know--I think "editing" will be around for a long time. In Star Trek (which has accurately predicted many things), it seems that "programming" is done mostly by putting together functional blocks. They somehow know how to interface with each other and transfer data. I wonder how much of programming is constantly re-inventing the wheel? I really get tired of writing simple dialogs just to get, for example, some selection criteria on which to base a query. It would be nice if we could automate the simpler things that we programmers do. Marc
-
I don't know--I think "editing" will be around for a long time. In Star Trek (which has accurately predicted many things), it seems that "programming" is done mostly by putting together functional blocks. They somehow know how to interface with each other and transfer data. I wonder how much of programming is constantly re-inventing the wheel? I really get tired of writing simple dialogs just to get, for example, some selection criteria on which to base a query. It would be nice if we could automate the simpler things that we programmers do. Marc
Marc Clifton wrote: I wonder how much of programming is constantly re-inventing the wheel? A massive percentage of programming must be the same old thing being repeated from one place to another. I liked the COM idea of just having coponents, like your "Star Trek functional Blocks" but it didn't really take off. Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
find out what he does in his spare time :) and whether hes a nice guy or not the rest is boring nerdy details Bryce
bryce wrote: find out what he does in his spare time Yeah, at the end of the day, you could end up with someone who can't code, so it would be best to find someone who was good to have around. :-) Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
Marc Clifton wrote: I wonder how much of programming is constantly re-inventing the wheel? A massive percentage of programming must be the same old thing being repeated from one place to another. I liked the COM idea of just having coponents, like your "Star Trek functional Blocks" but it didn't really take off. Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
Agreed. The whole COM/DCOM/CORBA/... was a great idea, but it takes so much low level glue to get two COM objects to share data. Consider pulling shape data out of a database and drawing the shapes in Visio. Yuck. And I don't think the XML/SOAP thing solves it, because while it "defines" the data and formats, it doesn't say how to "use" the data. We've got a long way to go. Marc