Interview questions (it's been a while)
-
I know other people have discussed this previously, but I'd like some fresh feedback. My boss just walked in and told me and another programmer that we need to be ready to ask questions of some interviewees tomorrow. So, I have two questions. 1) The obvious: what questions must be asked? 2) Even better: what are some good thought processes for me to go through in order to determine what I should ask? In order for you to answer the questions I'm asking -- we need someone who can handle at least C++ maintenance work and incremental feature additions. At most, we'd like a programmer that can pick up C# quickly if he hasn't already, and demonstrates the ability own a small C++ and/or C# project on his own. (I doubt we'll end up with all that we'd like with the offered salary, but dreaming never hurts.) We also use many support technologies like XML, XSLT, HTML, COM, TCP/IP sockets, SQL Server, and serial communications. Thanks for any feedback. John
-
I know other people have discussed this previously, but I'd like some fresh feedback. My boss just walked in and told me and another programmer that we need to be ready to ask questions of some interviewees tomorrow. So, I have two questions. 1) The obvious: what questions must be asked? 2) Even better: what are some good thought processes for me to go through in order to determine what I should ask? In order for you to answer the questions I'm asking -- we need someone who can handle at least C++ maintenance work and incremental feature additions. At most, we'd like a programmer that can pick up C# quickly if he hasn't already, and demonstrates the ability own a small C++ and/or C# project on his own. (I doubt we'll end up with all that we'd like with the offered salary, but dreaming never hurts.) We also use many support technologies like XML, XSLT, HTML, COM, TCP/IP sockets, SQL Server, and serial communications. Thanks for any feedback. John
First where is your company? C++: Make sure they know what a virtual function does, when you would use a virtual destructor. What is the difference between a struct and a class. I would ask questions that most people that have a firm understanding of C++ would know. THings that you have to know in order to write good quality C++. COM: This goes back to virtual functions and how the interfaces work. If you really want to know how much they know about COM, ask them about apartment threading and what needs to be done to insure proper thread synchronization between the different threads. C#: Ask them what they do know about C# or .Net. If they do not know anything ask them what they know. One thing you can do is ask what they think about VB, even be a little condescending toward the language when you ask. I have found people that bash other languages, and that right there to me says that they are not open-minded enough to learn new languages. XML / HTML: Ask how they used XML, and what way they prefer to manipulate XML with, the SAX API, XML DOM, hand written code. You should be able to get info on this. Sockets: The API for sockets are simple, but the things that you can do with them gets quite complicated. SO I would just ask what projects that they have done with sockets and a brief overview of how they implemented the project.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
I know other people have discussed this previously, but I'd like some fresh feedback. My boss just walked in and told me and another programmer that we need to be ready to ask questions of some interviewees tomorrow. So, I have two questions. 1) The obvious: what questions must be asked? 2) Even better: what are some good thought processes for me to go through in order to determine what I should ask? In order for you to answer the questions I'm asking -- we need someone who can handle at least C++ maintenance work and incremental feature additions. At most, we'd like a programmer that can pick up C# quickly if he hasn't already, and demonstrates the ability own a small C++ and/or C# project on his own. (I doubt we'll end up with all that we'd like with the offered salary, but dreaming never hurts.) We also use many support technologies like XML, XSLT, HTML, COM, TCP/IP sockets, SQL Server, and serial communications. Thanks for any feedback. John
It seems to me you are asking for quite a few varied skills. My advice is to find someone who learns fast in preference to someone who has 75% of the skills you are looking for. John Fisher wrote: So, I have two questions. 1) The obvious: what questions must be asked? 2) Even better: what are some good thought processes for me to go through in order to determine what I should ask? Do a search here in the Lounge for "Interview" and you'll get a good variation of answers. Regardz Colin J Davies
Sonork ID 100.9197:Colin
More about me :-)
-
I know other people have discussed this previously, but I'd like some fresh feedback. My boss just walked in and told me and another programmer that we need to be ready to ask questions of some interviewees tomorrow. So, I have two questions. 1) The obvious: what questions must be asked? 2) Even better: what are some good thought processes for me to go through in order to determine what I should ask? In order for you to answer the questions I'm asking -- we need someone who can handle at least C++ maintenance work and incremental feature additions. At most, we'd like a programmer that can pick up C# quickly if he hasn't already, and demonstrates the ability own a small C++ and/or C# project on his own. (I doubt we'll end up with all that we'd like with the offered salary, but dreaming never hurts.) We also use many support technologies like XML, XSLT, HTML, COM, TCP/IP sockets, SQL Server, and serial communications. Thanks for any feedback. John
yep, search the lounge as Colin said. Most important to test: Understanding of pointers, templates, OO design. These are quite elitaire - some people just "don't get it". Other "borderlines" of C++ can typically be learned (using STL, exceptions, etc.) A C++ programmer who doesn't understand pointers is IMO someone to be aware of, and he's probably better off with another language. OO design: careful with people that recite the principles, rather let him/her outline the design for two interacting classes (e.g. Point and Line, something very simple) Give a small task (two microscopic ones are better than one small) and see how s/he approaches it. E.g. a "Point" class could stimulate the questions like: a) which data type(s)? (int, float, double...) b) How many dimensions? (most will assume 2), c) would a template be a good idea? Most people won't ask - look what they do, then "change the specifications". [edit] like: "Oh, but I need 3 dimensions", or "we have to do calculations with doubles, but need them to store as floats for space conservation"[/edit] But think about potential "surprise" solutions ahead - some might suggest using std::pair or std::complex, or they come up immediately with a template. (For the latter, you could claim that you need the points in polar coordinates, or have frequent conversions beetween cartesian and polar.) be nice, if s/he doesn't grasp your question, try to give clues, if this doesn't help move on. Each medium project has a few of such "helper classes", which often make interesting design questions.
The earth is not dying. It is being killed.
-
I know other people have discussed this previously, but I'd like some fresh feedback. My boss just walked in and told me and another programmer that we need to be ready to ask questions of some interviewees tomorrow. So, I have two questions. 1) The obvious: what questions must be asked? 2) Even better: what are some good thought processes for me to go through in order to determine what I should ask? In order for you to answer the questions I'm asking -- we need someone who can handle at least C++ maintenance work and incremental feature additions. At most, we'd like a programmer that can pick up C# quickly if he hasn't already, and demonstrates the ability own a small C++ and/or C# project on his own. (I doubt we'll end up with all that we'd like with the offered salary, but dreaming never hurts.) We also use many support technologies like XML, XSLT, HTML, COM, TCP/IP sockets, SQL Server, and serial communications. Thanks for any feedback. John
John Fisher wrote: I doubt we'll end up with all that we'd like with the offered salary, but dreaming never hurts If the salary is low you need to adapt the questions the programmer profile you want (in that salary range). Mauricio Ritter - Brazil Sonorking now: 100.13560 Trank :beer: The alcohol is one of the greatest enemys of man, but a man who flee from his enemys is a coward. :beer:
-
I know other people have discussed this previously, but I'd like some fresh feedback. My boss just walked in and told me and another programmer that we need to be ready to ask questions of some interviewees tomorrow. So, I have two questions. 1) The obvious: what questions must be asked? 2) Even better: what are some good thought processes for me to go through in order to determine what I should ask? In order for you to answer the questions I'm asking -- we need someone who can handle at least C++ maintenance work and incremental feature additions. At most, we'd like a programmer that can pick up C# quickly if he hasn't already, and demonstrates the ability own a small C++ and/or C# project on his own. (I doubt we'll end up with all that we'd like with the offered salary, but dreaming never hurts.) We also use many support technologies like XML, XSLT, HTML, COM, TCP/IP sockets, SQL Server, and serial communications. Thanks for any feedback. John
Since it's for maintenance type work, you'll want to find out if they are suited. Someone who wants to work with the latest technology and cutting edge tools will likely feel stifled doing maintenance. I'd ask questions about how they go about solving problems, i.e. the process they use, instead of just focusing on technobabble. I also ask people how they learn new things. If they sound like they're depending on the company to fund their way through a bunch of tech training and seminars when the budget only allows for books and magazine subs, I get worried.
-
First where is your company? C++: Make sure they know what a virtual function does, when you would use a virtual destructor. What is the difference between a struct and a class. I would ask questions that most people that have a firm understanding of C++ would know. THings that you have to know in order to write good quality C++. COM: This goes back to virtual functions and how the interfaces work. If you really want to know how much they know about COM, ask them about apartment threading and what needs to be done to insure proper thread synchronization between the different threads. C#: Ask them what they do know about C# or .Net. If they do not know anything ask them what they know. One thing you can do is ask what they think about VB, even be a little condescending toward the language when you ask. I have found people that bash other languages, and that right there to me says that they are not open-minded enough to learn new languages. XML / HTML: Ask how they used XML, and what way they prefer to manipulate XML with, the SAX API, XML DOM, hand written code. You should be able to get info on this. Sockets: The API for sockets are simple, but the things that you can do with them gets quite complicated. SO I would just ask what projects that they have done with sockets and a brief overview of how they implemented the project.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!kilowatt wrote: First where is your company? La Crosse, Wisconsin. Really nice place, but it's on the lower end of the tech pay scale for some reason. Thanks for the suggestions, this is the kind of think I was hoping for. :) John
-
yep, search the lounge as Colin said. Most important to test: Understanding of pointers, templates, OO design. These are quite elitaire - some people just "don't get it". Other "borderlines" of C++ can typically be learned (using STL, exceptions, etc.) A C++ programmer who doesn't understand pointers is IMO someone to be aware of, and he's probably better off with another language. OO design: careful with people that recite the principles, rather let him/her outline the design for two interacting classes (e.g. Point and Line, something very simple) Give a small task (two microscopic ones are better than one small) and see how s/he approaches it. E.g. a "Point" class could stimulate the questions like: a) which data type(s)? (int, float, double...) b) How many dimensions? (most will assume 2), c) would a template be a good idea? Most people won't ask - look what they do, then "change the specifications". [edit] like: "Oh, but I need 3 dimensions", or "we have to do calculations with doubles, but need them to store as floats for space conservation"[/edit] But think about potential "surprise" solutions ahead - some might suggest using std::pair or std::complex, or they come up immediately with a template. (For the latter, you could claim that you need the points in polar coordinates, or have frequent conversions beetween cartesian and polar.) be nice, if s/he doesn't grasp your question, try to give clues, if this doesn't help move on. Each medium project has a few of such "helper classes", which often make interesting design questions.
The earth is not dying. It is being killed.
Thanks for the ideas. This being my first interview, your ideas have been helpful. John