Need help devising interview questions for a junior
-
A junior programmer with no experience of testing? That's not a junior programmer, that's a complete beginner!
Well, when I applied for my first job, a junior programmer meant that work experience is not required.
-
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.
I do the some of the interviewing for my company, here are some of the questions I like (points are made up for emphasis): ********************************************1**************************** -for the white board or paper test Devise a Recursively searchable tree node structure, and show me an implementation. -wait for the inevitable questions(a good thing) What am i to search for? (and other class specs) A: a string named Name. (+1 pt) What does the recursion return? A: the node of interest. (+5 pts, not -10 pts) Forward recursive or reverse recursive-(+10 pts if they know the difference) ... let them work it out... If they are interviewing without threading background I like to see that they use an iterator, if threading NO ITERATOR ..... (5pts) if they can reason out that they need a temp node for the return value of the recursion before they get that far... (7pts) If it works (10 pts) If they show me that it can be done in less then say 5 minutes. (10 pts) if they use encapsulation (as per the specs that they ask... (10 pts) Yadda-yadda *********************************2************************************* Usually try to find one question which is very trivial for one or two of the random things which they claim they know.. ex: php:: Show me how to print the third member of the array bob. Javascript:: what is the difference between '==' and '===' ? ***********************************3*********************************** Ask at least one question with well defined specs up front but many "suitable" ways to answer it... Reverse the string "the fuzzy red fox". - check to see if they understand the conventions of whichever language you are using for strings, characters, and arrays. you also get to see if they are elegant in their choice of variable names, loop structure, and overall basic programming capabilities.. ********************************** 4 ***************** {Are you an active learner... etc.} do you have any personal projects, if so what.. {are you a member of a community} Do you frequent any forums, if so which one is your favorite and why? (plus 10000 pts if they say codeproject :cool: ) .. if they have a break in their employment history... What have you been doing to stay current with technologies..? ************************** summary ******************************* we like to stress the interviewee out to the point where they might be shaking a little (pressure stress) to see how clear headed they react and work under pressure. Check to see that th
-
Ok. Now, I understand what you are getting at. I wonder if there is a better way to ask the question though. The question doesn't ask anything about the exhaustive nature of the testing. It only asks the reason for doing it in the first place.
These are starting points for broader discussions. They aren't questions that someone can get right or wrong. For example, once they've written an answer to: 1. Write code do determine how many bits are "on" in a byte I'd probably introduce some more constrainsts. Some candidates use shift operatators and shift the byte left or right one place eight times, and test the most/least significant bit as appropriate. In that case, I'd ask how they would improve the speed. You could for, example, create a 256 entry lookup table, and use the byte as an index into that. Very quick result. You can then use that as a starting point for a discussion on whether the lookup table should be static, or built at runtime, and see what criteria they would apply to that decision. If they started with the lookup table approach, you can still have the dynamic vs static discussion, and then ask what they would do in a memory-constrained situation, where building a table was impossible. Essentially, I'm trying to engage them, to see a) how they interact with other people b) what their problem-solving approach is I'm most definitely not trying to get them to sit an exam, which gets marked.
-
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.Electron Shepherd wrote:
The point is to prove it doesn't work (ie find a defect)
I'd back that up completely. Glenford Myers in his book 'The Art of Software Testing (2nd edn.)' argues that testing to demonstrate that errors are not present is impossible, and that proving that a program does what it is supposed to do does not prove that the program is error free. Therefore, Myers defines black box testing as “The destructive process of trying to find the errors (whose presence is assumed) in a program.” Myers, G. (2004) The Art of Software Testing (2nd edn.) Hoboken: John Wiley & Sons
Nobody can get the truth out of me because even I don't know what it is. I keep myself in a constant state of utter confusion. - Col. Flagg
-
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!
RavensCry wrote:
I did once write some interview questions for a junior and tried them out on my own team, they all failed!
Doesn't that tell you something :laugh:
Nobody can get the truth out of me because even I don't know what it is. I keep myself in a constant state of utter confusion. - Col. Flagg
-
These are starting points for broader discussions. They aren't questions that someone can get right or wrong. For example, once they've written an answer to: 1. Write code do determine how many bits are "on" in a byte I'd probably introduce some more constrainsts. Some candidates use shift operatators and shift the byte left or right one place eight times, and test the most/least significant bit as appropriate. In that case, I'd ask how they would improve the speed. You could for, example, create a 256 entry lookup table, and use the byte as an index into that. Very quick result. You can then use that as a starting point for a discussion on whether the lookup table should be static, or built at runtime, and see what criteria they would apply to that decision. If they started with the lookup table approach, you can still have the dynamic vs static discussion, and then ask what they would do in a memory-constrained situation, where building a table was impossible. Essentially, I'm trying to engage them, to see a) how they interact with other people b) what their problem-solving approach is I'm most definitely not trying to get them to sit an exam, which gets marked.
That is what you should be doing. I guess I am so used to people running an interview like an exam when they ask these sorts of questions that I am not expecting a logical approach from anyone anymore.
-
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.
Besides asking about how he/she individually contributed to projects ask them questions regarding the technologies and roles listed on their resumes. For example a prospective hire labeled himself as a database admin and programmer. When probing further into the database admin aspect we come to find he had no practical work experience as database admin other than a college class. Yet he considered himself an admin. This has happened time & time again.
-
Electron Shepherd wrote:
The point is to prove it doesn't work (ie find a defect)
I'd back that up completely. Glenford Myers in his book 'The Art of Software Testing (2nd edn.)' argues that testing to demonstrate that errors are not present is impossible, and that proving that a program does what it is supposed to do does not prove that the program is error free. Therefore, Myers defines black box testing as “The destructive process of trying to find the errors (whose presence is assumed) in a program.” Myers, G. (2004) The Art of Software Testing (2nd edn.) Hoboken: John Wiley & Sons
Nobody can get the truth out of me because even I don't know what it is. I keep myself in a constant state of utter confusion. - Col. Flagg
And this is a philosophical point that is obviously beyond the ken of most people, else nobody would be writing about it as though it were a big deal. Just look at any religious person who mocks agnostics for not proving God doesn't exist. We all use shorthand concepts for better communication. Ask most programmers who understand that their tests are trying to break the software and they will tell you the purpose of the test is to make sure the program works. Just because they aren't pedantically perfect doesn't mean they are wrongheaded, or clueless, or whatever it is you think that question is supposed to tell you. It is a clue that they might not get it, but it could just be that they never thought about their use of language in that particular instance and how it communicates something different from what they actually do. You would need to follow up on that question if they gave the "wrong" answer, else you are throwing babies out with bathwater.
Narf.
-
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[^]
First, I'd go with spoons: anything you can eat with chopsticks you can eat with a spoon but not the other way round. Second, whatever happened to the spork? Third, ask them about IDisposable ... when and why would you use it. And ask them if you ever need to explicitly call the Dispose method of a winform (and if so, when).
-
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.
there are some silly posts and some serious ones here; I'm not an interviewer much... for like permanent hire but I talk to developers all the time sizing them up so I can see where they might be useful. In my experience: asking for some strange abstract pseudo anything; or complex threading questions shouldn't make or break your junior applicant UNLESS you have a specific role you're trying to fill that such questions apply and have merit: I believe the technical questions should revolve around the job itself and maybe a little beyond. Asking me about pseudo code that's abstract or low level threading questions for a job writing php and web pages ... well; you might not hire the perfect candidate because you kicked him or her to the curb with your completely random "test of skill question" that has no bearing on the task at hand: filling the specific role or roles you hiring for. If you're hiring a junior that you'd like to groom to be a company "talent" you want to hang on to... that's one thing; hammer them at least to see where there are; not just to say yes or no to hiring them but to see how they'd fit you and your company's long term vision. I'm no expert here.. but if I was applying for a PHP job and I got asked a question or given a test for operating system kernel design... I'd walk depending on the answer to this question: Is there a systems analyst position open that pays more than PHP crap? If so.. I'd answer the question or perform the test... otherwise I'd walk away and laugh as the pay rate they are offering for the knowledge they are asking for... It'd be a good laugh though
Know way too many languages... master of none!
-
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?
Um ... to keep the customer happy? ... because if I don't, I'll feel bad about myself for releasing crappy software? ... so I don't get fired? :^) Surely, all the 'real' reasons (to find the defects / to prove there are no (easily encountered defects) / etc.) really boil down to one of the above. I write software (a) because I enjoy it and (b) because it's my job. If I fail to test my work I'll know I've done a bad job and someone will get unhappy. And I'll either be working late to fix what I should have found and fixed earlier, or I'm polishing up my CV and on the job hunt again. Not that I would be pleased with an interview candidate who (only?) gave such flippant answers to the question: "What's the point of testing software?", of course, because demonstrating respect is something I also look for in interview candidates.
-
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.
When I'm interviewing candidates I always (try to) start by asking myself "what skills, attitudes and aptitudes should I expect of the candidate given their experience?" The CV/resume is very useful at this point - it says what they (claim they) have been doing - from which you can make a guess at the skills they've developed: > have they been exposed to written specs and expected to turn them into implementation designs? (If so - ask about what they did/how they did it/how they interacted with peers to ensure that they'd created valid and complete designs, etc.) > have they written a Windows service (for example)? If so, what Win32 or .Net APIs should they be familiar with having done so? > have they created (part of) an app with a heavy UI? Perhaps they've worked with Infragistics, DevExpress or some other UI package. If so, are they as familiar with the parts of the package as you'd expect them to be, given their claims? If they've done .Net UI work, are they familiar with the
usingstatement (as distinct from theusingdirective)? > etc. What technology skills should the candidate have learned while doing what they claimed they did in their last job(s)? Given that the candidate is applying for a programming job there are some fundamental topics a candidate could (IMO) be expected to know: > How do you set up a new project in the IDE? > How do you add references to DLLs/libraries to a project in the IDE? > (possibly) If your project is a DLL (for candidates who have created DLLs/libraries) how do you configure the project to debug it in the IDE? > (in Visual Studio) What's the difference between a project and a solution? What is a post-build step? > (in other IDEs) - ask about how projects are built (does any platform still expose Make to developers???) > (possibly) "what version control system(s) have you used, and what check-in policies did your last employer use?" > (in .Net) How do you write debug information to the output window? (And, if they give a sufficient answer to that: what namespace contains the Debug object?) BUT - what fundamental language and framework/library topics can you expect, regardless of experience? I'd say that there are probably few topics that you can be sure of (regardless of experience) but many that are possible/likely: > what areExceptions, and tell me how you have used them? > what is the difference between theforand theforeachstatements? > tell me -
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.
I liked to ask a Kobiyashi Maru (sp). Ask them something that they can't possibly do in order to see how they handle failing. Back in my technician days, we'd automate a lot of bench testing thru Nat'l INstruments products and HPIB, etc. So I would set up a power supply and an oscillscope and a little program that would step the voltage up from zero to 10 volts stepping by 2 volts. Then I would ask the target to vary the program so that it stepped by one volt or to go from 6 to 26 volts. It was always funny to see their faces when the power supply wouldn't go above 20 volts because it simply wasn't designed to and to give them hints on what might be "wrong" with "their programs".
-
Forks
"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
Knives?! (Knives at 40 paces.)
-
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")This is topic that I have struggled with for 40 years. It can be complex because good programmers are a complex mix of intelligence, natural ability, determination, creativity, experience, training, personal habits, philosophy. ... I have hired many and fired many. What I can contribute here is perhaps offering some thoughts on what to consider as questions to include. Of course there is no perfect candidate but there is always a best one. There is a lot of information that I do not see in the question that would skew the selection process: Type of projects? Business Applications, Non-business Applications, Utilities, OS, Language Development, Web or Desktop, ... Type of user? in-house or customer, onsite or remote, ... Project Group? Office-based or not, Strong peer group or not, ... Project History? Creating new apps, maintenance programming, ... We were always advised by our attorneys to be careful to not ask questions that could be considered discriminating. This can complicate things. I think there are two basic categories to any employee. A good employee: ================= If they are brilliant but emotionally or socially inept you may never get what they are capable of. Follows direction Gets along with others Takes a genuine interest in the work/is motivated Will work to a schedule ... How do you determine this? --------------------------- Ask questions that probe these areas without being too direct. For example: (Assumes that this is not a telecommute necessarily) "What things do you think that management and your peers should consider to help you meet your project goals?" "What are your hobbies and interests?" "Do you have any programmers that you model yourself after? Gosling, Torvalds, Stallman, ....?" "What kind of project scheduling are you used to, do you prefer, would you suggest works the best for you?" ... Good at the job: ================ Without some natural ability they may not be right for you unless you have a strong support system and peer group. Has related training and experience Quick witted Problem solver Can demonstrate the above in a test ... How do you determine this? -------------------------- Provide some typical good and bad code examples they will be required to create or maintain and as them to describe: 1. What the code does? 2. How to add a feature? 3. How the code could be improved/what they think of the code style? Consider giving them a math test to do with a time limit. Gear it to deter
-
I liked to ask a Kobiyashi Maru (sp). Ask them something that they can't possibly do in order to see how they handle failing. Back in my technician days, we'd automate a lot of bench testing thru Nat'l INstruments products and HPIB, etc. So I would set up a power supply and an oscillscope and a little program that would step the voltage up from zero to 10 volts stepping by 2 volts. Then I would ask the target to vary the program so that it stepped by one volt or to go from 6 to 26 volts. It was always funny to see their faces when the power supply wouldn't go above 20 volts because it simply wasn't designed to and to give them hints on what might be "wrong" with "their programs".
For that matter, go to a room where you can open the window, nail it shut, then ask them to open the window. Go to a round room and ask the to sit in the corner. Go to a square room and ask them to calculate the radius of the room. Lots of fun.
-
For that matter, go to a room where you can open the window, nail it shut, then ask them to open the window. Go to a round room and ask the to sit in the corner. Go to a square room and ask them to calculate the radius of the room. Lots of fun.
Sounds like you got caught on one of these... and are still resenting it.
-
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.
I always ask a simple first question: How long would it take you to code a login page. Reason one: if they have never developed a basic application with a login, they will definitely fail to see a big picture. Reason two: If their answer is more than 15 minutes, they have never done one and have no clear idea how to code a simple two question validation page. End of interview, the rest is just what they and you may or may not have encountered in coding.
-
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.