Need help devising interview questions for a junior
-
Fork off!
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
For forks sake, is that best forking response you got? :)
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
For forks sake, is that best forking response you got? :)
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
For forks sake, is that best forking response you got? :)
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
Think of a small program, that you could write in say, four hours. Give them VS2008 / 10 / whatever you use, four hours and a spec. See how they get on. Other ideas: We've previously interviewed for a C++ / Windows position, and asked questions like: C / C++ specific, testing basic knowledge of bit operators and pointers. 1. Write code do determine how many bits are "on" in a byte. 2. Write code to reverse a string in place in a buffer. 3. Write the standard
atoifunction from scratch Windows Specific 1. When do you put elipsis on a menu or button? 2. Why would you use threads in an application? (we look for three different scenarios) General software engineering What's the point of testing software? (you'd be amazed how many people say "to make sure it works")Electron Shepherd wrote:
What's the point of testing software? (you'd be amazed how many people say "to make sure it works")
OK, I'll bite! That *is* the point, isn't it? I can think of expanding the idea, like "to make sure it works against specification X", "to make sure it works consistently", " to make sure it works even in the face of adversity", but they're all expansions on the first point. Iain c++, q2 - My first thought was swapping end and start char / wchars, then work to the middle, but what about utf8? Or do I win a cookie for thinking about that?
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
-
Electron Shepherd wrote:
What's the point of testing software? (you'd be amazed how many people say "to make sure it works")
OK, I'll bite! That *is* the point, isn't it? I can think of expanding the idea, like "to make sure it works against specification X", "to make sure it works consistently", " to make sure it works even in the face of adversity", but they're all expansions on the first point. Iain c++, q2 - My first thought was swapping end and start char / wchars, then work to the middle, but what about utf8? Or do I win a cookie for thinking about that?
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
Iain Clarke, Warrior Programmer wrote:
OK, I'll bite! That *is* the point, isn't
No. The point is to prove it doesn't work (ie find a defect) For any piece of software, one of these three must be true: 1) The software contains no defects. 2) The software contains at least one defect, and I know what it is. 3) The software contains at least one defect, and I do not know what it is. The role of the testing process is to determine which one is true. If 1) is true, you are finished. Release the product. If 2) is true, you fix the defect, and reevaluate. If 3) is true, you continue testing until either 1) or 2) is true. So, the point of testing is to move from 3) to either 1) or 2), and that involves finding defects. Of course, at some point, you have to take the view that "absence of proof is proof of absence", in that you can't find any more defects, so you assume there are none (ie you assume 1) is true, when it may not be). When and how you make that decision is what puts the 'engineering' into 'software engineering', and one of the things that makes the question a jumping off point for a broader discussion.
Iain Clarke, Warrior Programmer wrote:
but what about utf8?
Indeed. One of the points of the question is to see if the candidate things in terms of
char*only, or can think about other aspects of a (deliberately) vague spec. For example, I didn't even say if the buffer was null-terminated or not. -
Need help from people with experience of interviewing, rather than being interview. I have been tasked with creating some .net question for the interview for a junior and I have no idea where to start and would love to have some sensible and as well as wacky (because I know here I'll get some!) from people that have had such experience
As barmey as a sack of badgers Dude, if I knew what I was doing in life, I'd be rich, retired, dating a supermodel and laughing at the rest of you from the sidelines.
-
Need help from people with experience of interviewing, rather than being interview. I have been tasked with creating some .net question for the interview for a junior and I have no idea where to start and would love to have some sensible and as well as wacky (because I know here I'll get some!) from people that have had such experience
As barmey as a sack of badgers Dude, if I knew what I was doing in life, I'd be rich, retired, dating a supermodel and laughing at the rest of you from the sidelines.
Keep a straight face and ask him to write an intractable problem in pseudo code. Time him.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
Need help from people with experience of interviewing, rather than being interview. I have been tasked with creating some .net question for the interview for a junior and I have no idea where to start and would love to have some sensible and as well as wacky (because I know here I'll get some!) from people that have had such experience
As barmey as a sack of badgers Dude, if I knew what I was doing in life, I'd be rich, retired, dating a supermodel and laughing at the rest of you from the sidelines.
Try and cover the basics, so things like: "Give an example of when you might use a static field on a class" "What's the difference between an interface and an abstract class" "Describe the purpose of the 'ref' keyword in a methods signature" Ask them about database interaction: "How would you execute a SELECT statement against a database" "Which method would you use to retrieve the value from the first column of the first row" Perhaps something on using things like app.config files? Also maybe a couple of questions to demonstrate that they know the difference between passing by value/reference. It's outside of .net but maybe something about version control as well? Hope that helps
-
Need help from people with experience of interviewing, rather than being interview. I have been tasked with creating some .net question for the interview for a junior and I have no idea where to start and would love to have some sensible and as well as wacky (because I know here I'll get some!) from people that have had such experience
As barmey as a sack of badgers Dude, if I knew what I was doing in life, I'd be rich, retired, dating a supermodel and laughing at the rest of you from the sidelines.
-
Try and cover the basics, so things like: "Give an example of when you might use a static field on a class" "What's the difference between an interface and an abstract class" "Describe the purpose of the 'ref' keyword in a methods signature" Ask them about database interaction: "How would you execute a SELECT statement against a database" "Which method would you use to retrieve the value from the first column of the first row" Perhaps something on using things like app.config files? Also maybe a couple of questions to demonstrate that they know the difference between passing by value/reference. It's outside of .net but maybe something about version control as well? Hope that helps
-
Need help from people with experience of interviewing, rather than being interview. I have been tasked with creating some .net question for the interview for a junior and I have no idea where to start and would love to have some sensible and as well as wacky (because I know here I'll get some!) from people that have had such experience
As barmey as a sack of badgers Dude, if I knew what I was doing in life, I'd be rich, retired, dating a supermodel and laughing at the rest of you from the sidelines.
The easiest way for me to have an "idea" of the knowledge of the candidate was to develop a written test with general concepts of the thecnology and a few logic and OO questions. Then just read the test, see how he performs and then talk to him about general stuff, way he works/worked in the past, prospective about the future, etc.
-
Need help from people with experience of interviewing, rather than being interview. I have been tasked with creating some .net question for the interview for a junior and I have no idea where to start and would love to have some sensible and as well as wacky (because I know here I'll get some!) from people that have had such experience
As barmey as a sack of badgers Dude, if I knew what I was doing in life, I'd be rich, retired, dating a supermodel and laughing at the rest of you from the sidelines.
First, what not to do. Normally the interviewers' objective is to find out how much the interviewee knows and what experience they've had. Asking trick questions and posing zany challenges will not help you find this out - they are just traps that bad interviewers fall into. Also if you go in (or send the interviewer in) with a set of questions about .net it turns from an interview into an exam. You could do that by email. Waste of interviewing time so that is something else to avoid. Instead, just ask them what you want to know. A good technique is to start by asking them what they've done (I'm asuming that someone else is dealing with questions designed to put them at ease and to check their applications - those a pretty essential ways of starting the interview). So your questions can start by asking the junior just how much .net experience they have had. Stop. Let them speak, and listen. If they say some interesting stuff then pick up on it. The purpose of your questioning now has to be to find out how much of what they are claiming they did themselves: if part of a team what was their role? What did they contribute specifically? e.g. answer: we designed a piece of software that did wonderful things. follow-up question: yes but which part of it did you personally work on, what was your exact contribution (to be asked every time they say "we did" instead of "I did"). Then shut up and listen. Then probe specifics, to see whether they can support their claims by demonstrating a genuine understanding of the task they are describing. What else have they done? - same pattern: find out how much was their work and how much they understood. Repeat until you feel you have got a measure of the candidate's abilities. They might be nervous to the extent that they dry up, in which case it is OK to lead them gently, using their application as a way in. But stop at regular intervals and listen. Try to get them doing 95% of the talking. Above all, if you are the interviewer resist the temptation to pontificate or otherwise show off. This isn't the time or place for that. HTH
-
RavensCry wrote:
Ask them about database interaction
Aw why :( That's not even part of .NET.. Is that even a basic thing? (I would be unable to answer those two questions)
-
Just ask "Spoons or Chopsticks?". Watch their faces, it befuddles them. Then ask a technical question, see if their brains can swiftly recover, it is a good technique for whittling out the permanently bewildered.
------------------------------------ I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave CCC League Table Link CCC Link[^]
Definatly Chopsticks for foods which are indigenous to Asia.. else spoons. :laugh:
I'd blame it on the Brain farts.. But let's be honest, it really is more like a Methane factory between my ears some days then it is anything else...
-----
"The conversations he was having with himself were becoming ominous."-.. On the radio... -
Iain Clarke, Warrior Programmer wrote:
OK, I'll bite! That *is* the point, isn't
No. The point is to prove it doesn't work (ie find a defect) For any piece of software, one of these three must be true: 1) The software contains no defects. 2) The software contains at least one defect, and I know what it is. 3) The software contains at least one defect, and I do not know what it is. The role of the testing process is to determine which one is true. If 1) is true, you are finished. Release the product. If 2) is true, you fix the defect, and reevaluate. If 3) is true, you continue testing until either 1) or 2) is true. So, the point of testing is to move from 3) to either 1) or 2), and that involves finding defects. Of course, at some point, you have to take the view that "absence of proof is proof of absence", in that you can't find any more defects, so you assume there are none (ie you assume 1) is true, when it may not be). When and how you make that decision is what puts the 'engineering' into 'software engineering', and one of the things that makes the question a jumping off point for a broader discussion.
Iain Clarke, Warrior Programmer wrote:
but what about utf8?
Indeed. One of the points of the question is to see if the candidate things in terms of
char*only, or can think about other aspects of a (deliberately) vague spec. For example, I didn't even say if the buffer was null-terminated or not.You're mostly playing a word game with this. How do you make sure something works? Make sure it does what it says it will do. A bug will keep the software from doing what it is said to do. I will say that you have been out of the engineering business far too long if you actually think that your 1) is possible. Bug-free code does not exist except in small examples where no user interaction is needed and only very basic logic is used. Even then, you could find a mistake or vulnerability somewhere.
-
Think of a small program, that you could write in say, four hours. Give them VS2008 / 10 / whatever you use, four hours and a spec. See how they get on. Other ideas: We've previously interviewed for a C++ / Windows position, and asked questions like: C / C++ specific, testing basic knowledge of bit operators and pointers. 1. Write code do determine how many bits are "on" in a byte. 2. Write code to reverse a string in place in a buffer. 3. Write the standard
atoifunction from scratch Windows Specific 1. When do you put elipsis on a menu or button? 2. Why would you use threads in an application? (we look for three different scenarios) General software engineering What's the point of testing software? (you'd be amazed how many people say "to make sure it works")Although I take issue with the last question as you can see below, I do like the way you think for the other questions. You seem to be more interested in the person's reasoning ability than their extensive knowledge of library 'X' that could be looked up in any real life situation. I run into too many "ability tests" from headhunting companies that focus too much on whether or not you've used a specific facet of the language instead of whether you can use tools to solve a problem.
-
Although I take issue with the last question as you can see below, I do like the way you think for the other questions. You seem to be more interested in the person's reasoning ability than their extensive knowledge of library 'X' that could be looked up in any real life situation. I run into too many "ability tests" from headhunting companies that focus too much on whether or not you've used a specific facet of the language instead of whether you can use tools to solve a problem.
Someone who knows everything about a language, but took 10 years to learn it, is, I think, much less valuable than someone who knows nothing about a language, but can learn it in one year. To summarise in a cute phrase, I'm trying to assess capability, not abiity.
-
You're mostly playing a word game with this. How do you make sure something works? Make sure it does what it says it will do. A bug will keep the software from doing what it is said to do. I will say that you have been out of the engineering business far too long if you actually think that your 1) is possible. Bug-free code does not exist except in small examples where no user interaction is needed and only very basic logic is used. Even then, you could find a mistake or vulnerability somewhere.
Billy Howell wrote:
You're mostly playing a word game with this.
NO, I'm looking for an approach and an attitude.
Billy Howell wrote:
Make sure it does what it says it will do.
I write a program, for which the spec is "accept three numbers, add them up, and print the total". I enter the numbers 2 and 2, and it prints 4. I enter the numbers 1, 2 and 3, and it prints 6. Clearly the program does what is says it will do, so it's tested. In fact, it multiplies them, not adds them, but still prints the correct answers. So my tests don't find my bug, but instead seem to show the program works. That is a contrived example, and yes, almost any other combination of numbers would show the bug. But I've seen too many developers who think their program is wonderful, and tiptoe round the testing, only trying to prove it works, and confirm their own programming abilities. We're getting into psychology rather than pure software engineering, but one of the things I'm looking for is the ability to want to try to knock down the thing you've just built, in an effort to prove how strong it is.
-
And I was holding back, maybe I'm just evil when it comes to potential employees :wtf: I did once write some interview questions for a junior and tried them out on my own team, they all failed!
You evil person :) I'd probably ask about something hard about algorithms and datastructures, and something "easy for me" about bithacks. That's probably evil too :) Still if someone doesn't even understand a Min-Heap, or tests for "is a power of 2" with a for loop and Math.Pow, there is something wrong with their education..
-
Need help from people with experience of interviewing, rather than being interview. I have been tasked with creating some .net question for the interview for a junior and I have no idea where to start and would love to have some sensible and as well as wacky (because I know here I'll get some!) from people that have had such experience
As barmey as a sack of badgers Dude, if I knew what I was doing in life, I'd be rich, retired, dating a supermodel and laughing at the rest of you from the sidelines.
You can work them out pretty quickly by not only asking the differences between interfaces and base classes but how and when it is best to apply each. I wouldn't bother asking silly questions like the number of piano tuners in london. Remeber, you're hiring a junior developer. They're likely to be a bit shy so don't terrify them within 2 minutes of the interview starting.