What every programmer should know?
-
I am trying to come up with a set of questions that will form the initial screening round for all candiates at our company. Any thoughts about questions/concepts that should defintely be known by any programmer?
I always think that the idea of a compiler that compiles another compiler or itself is rather incestuous in a binary way. - Colin Davies My .Net Blog
-
I am trying to come up with a set of questions that will form the initial screening round for all candiates at our company. Any thoughts about questions/concepts that should defintely be known by any programmer?
I always think that the idea of a compiler that compiles another compiler or itself is rather incestuous in a binary way. - Colin Davies My .Net Blog
1. Explain some difference between an abstract class and an interface 2. what is a virtual method 3. Explain some difference between in process and out of process 4. How big is a byte in bits 5. Describe the decorator design pattern Regards Ray "Je Suis Mort De Rire"
-
1. Explain some difference between an abstract class and an interface 2. what is a virtual method 3. Explain some difference between in process and out of process 4. How big is a byte in bits 5. Describe the decorator design pattern Regards Ray "Je Suis Mort De Rire"
Ooooerrrrr - looks like I'd better find a different job :) I still remember having to write your own code in FORTRAN rather than be a cut and paste merchant being pampered by colour coded Intellisense - ahh proper programming - those were the days :)
-
I am trying to come up with a set of questions that will form the initial screening round for all candiates at our company. Any thoughts about questions/concepts that should defintely be known by any programmer?
I always think that the idea of a compiler that compiles another compiler or itself is rather incestuous in a binary way. - Colin Davies My .Net Blog
I'm confused by your question. You're obviously a programmer so why would you need to ask for a list of questions that every developer should know? Cheers, Tom Archer - Visual C++ MVP Archer Consulting Group "So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
-
I am trying to come up with a set of questions that will form the initial screening round for all candiates at our company. Any thoughts about questions/concepts that should defintely be known by any programmer?
I always think that the idea of a compiler that compiles another compiler or itself is rather incestuous in a binary way. - Colin Davies My .Net Blog
I have some collection of question at quiz and puzzels on: http://www.priyank.in/ Hope you like.
-
1. Explain some difference between an abstract class and an interface 2. what is a virtual method 3. Explain some difference between in process and out of process 4. How big is a byte in bits 5. Describe the decorator design pattern Regards Ray "Je Suis Mort De Rire"
Ray Kinsella wrote: 1. Explain some difference between an abstract class and an interface You cannot make bugs in interface - unlike abstract class - you can make only design mistakes. Ray Kinsella wrote: 2. what is a virtual method
void CheckSecuritySettings() { // TODO }Ray Kinsella wrote: 3. Explain some difference between in process and out of process in-process is cool, out-process sucks. Ray Kinsella wrote: 4. How big is a byte in bits *that* big (showing with both hands) Ray Kinsella wrote: 5. Describe the decorator design pattern That's a mess what Visual Studio HTML designer produce from your markup. now, would you give me a job? :-D David -
Ray Kinsella wrote: 1. Explain some difference between an abstract class and an interface You cannot make bugs in interface - unlike abstract class - you can make only design mistakes. Ray Kinsella wrote: 2. what is a virtual method
void CheckSecuritySettings() { // TODO }Ray Kinsella wrote: 3. Explain some difference between in process and out of process in-process is cool, out-process sucks. Ray Kinsella wrote: 4. How big is a byte in bits *that* big (showing with both hands) Ray Kinsella wrote: 5. Describe the decorator design pattern That's a mess what Visual Studio HTML designer produce from your markup. now, would you give me a job? :-D Davidsure ... I would let you "program" in vb ... Regards Ray "Je Suis Mort De Rire"
-
I am trying to come up with a set of questions that will form the initial screening round for all candiates at our company. Any thoughts about questions/concepts that should defintely be known by any programmer?
I always think that the idea of a compiler that compiles another compiler or itself is rather incestuous in a binary way. - Colin Davies My .Net Blog
I leave the hard technical questions to others, I'm rather eccentric. What every programmer should know: Why he/she wants to be a programmer. (will they stick out the job or become an artist and leave) Where he/she wants to be in the company 10/20 years from now. (do they even want to stick around for more than 4 years before moving on? Do they only want to code [like me], or have they ambitions of project lead, or management?) Can he/she ask for help rather than punching a brick wall for a month. How to document code. _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
sure ... I would let you "program" in vb ... Regards Ray "Je Suis Mort De Rire"
:-D I do program in VB... well no... I am moving project to .NET (C#)- but still, I have to read VB6 code David
-
I am trying to come up with a set of questions that will form the initial screening round for all candiates at our company. Any thoughts about questions/concepts that should defintely be known by any programmer?
I always think that the idea of a compiler that compiles another compiler or itself is rather incestuous in a binary way. - Colin Davies My .Net Blog
a lot of swear words? preferably including a few new ones for me to learn and use on those *really* bad days :) zen is the art of being at one with the two'ness
-
I am trying to come up with a set of questions that will form the initial screening round for all candiates at our company. Any thoughts about questions/concepts that should defintely be known by any programmer?
I always think that the idea of a compiler that compiles another compiler or itself is rather incestuous in a binary way. - Colin Davies My .Net Blog
First and foremost, how to write well.
-
a lot of swear words? preferably including a few new ones for me to learn and use on those *really* bad days :) zen is the art of being at one with the two'ness
feline_dracoform wrote: preferably including a few new ones for me to learn and use on those *really* bad days I can't speak more than English, but I can swear a little in 3 languages. _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I am trying to come up with a set of questions that will form the initial screening round for all candiates at our company. Any thoughts about questions/concepts that should defintely be known by any programmer?
I always think that the idea of a compiler that compiles another compiler or itself is rather incestuous in a binary way. - Colin Davies My .Net Blog
Personally, I've always thought that interviewers that prepare technical questions ahead of time are missing the total point. You cannot do that and do much justice to the applicant. I mean yeah, you can discuss for loops, recursion, dynamic programming and sorting. Stick to the basics for your canned questions (if you are going to use them, I think canned questions stink). I have yet to be in an interview where the skills in question were not quickly observed or not. You need to look at the applicants resume. I'd go through it carefully. If after going through it carefully you still like the candidate you need to do some more research. If they indicate you can contact present/past employers do it. Don't ask the employers about the candidate ask the employers about the systems the candidate worked on. What challenges had to be overcome in writing the system? What philosophies were used to manage changes, bugs and new code. Start forming an idea in your head of the skills the developer should be bringing to the table after you've done some research. Then go in to the interview with a customized set of questions. Talk about former systems and the challenges. Get a feel for how the developer approaches solving problems. I've always believed a developers answers to solving problems are important but nothing in comparison to how he/she approaches solving problems. Get a feel for that. Get a feel for what it would be like to work with that developer. Most importantly, if your business frequently requires unusual hours or a heavy support burden after hours make that known up front. Developers will piss and moan until the cows come home about support rotation and trouble-shooting. If you make it known in the interview what the expectations are and they still accept the job then you have grounds for saying, "Hey, we told you up front. You accepted the job. Now cork it and get it done." My advice, don't can or script your interviews in an assembly line way. Take the time each applicant really deserves to prepare an interview that is customized for them. They've taken the time to select you as a company. If they are worth anything they have learned as much about your company as they could before coming there. It's your obligation to do the same about them. I think it establishes a healthy relationship from the beginning and it keeps everything in the proper context for an interview. You can talk about design patterns if you wish but if the developers experience has never involved the use of patterns then he/sh
-
Personally, I've always thought that interviewers that prepare technical questions ahead of time are missing the total point. You cannot do that and do much justice to the applicant. I mean yeah, you can discuss for loops, recursion, dynamic programming and sorting. Stick to the basics for your canned questions (if you are going to use them, I think canned questions stink). I have yet to be in an interview where the skills in question were not quickly observed or not. You need to look at the applicants resume. I'd go through it carefully. If after going through it carefully you still like the candidate you need to do some more research. If they indicate you can contact present/past employers do it. Don't ask the employers about the candidate ask the employers about the systems the candidate worked on. What challenges had to be overcome in writing the system? What philosophies were used to manage changes, bugs and new code. Start forming an idea in your head of the skills the developer should be bringing to the table after you've done some research. Then go in to the interview with a customized set of questions. Talk about former systems and the challenges. Get a feel for how the developer approaches solving problems. I've always believed a developers answers to solving problems are important but nothing in comparison to how he/she approaches solving problems. Get a feel for that. Get a feel for what it would be like to work with that developer. Most importantly, if your business frequently requires unusual hours or a heavy support burden after hours make that known up front. Developers will piss and moan until the cows come home about support rotation and trouble-shooting. If you make it known in the interview what the expectations are and they still accept the job then you have grounds for saying, "Hey, we told you up front. You accepted the job. Now cork it and get it done." My advice, don't can or script your interviews in an assembly line way. Take the time each applicant really deserves to prepare an interview that is customized for them. They've taken the time to select you as a company. If they are worth anything they have learned as much about your company as they could before coming there. It's your obligation to do the same about them. I think it establishes a healthy relationship from the beginning and it keeps everything in the proper context for an interview. You can talk about design patterns if you wish but if the developers experience has never involved the use of patterns then he/sh
Great points, c-f. I had written a similar post and the site ate it, but you said it extremely well. Cheers, Tom Archer - Visual C++ MVP Archer Consulting Group "So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
-
feline_dracoform wrote: preferably including a few new ones for me to learn and use on those *really* bad days I can't speak more than English, but I can swear a little in 3 languages. _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
yep, you are through to the second round of interviews :) zen is the art of being at one with the two'ness
-
I am trying to come up with a set of questions that will form the initial screening round for all candiates at our company. Any thoughts about questions/concepts that should defintely be known by any programmer?
I always think that the idea of a compiler that compiles another compiler or itself is rather incestuous in a binary way. - Colin Davies My .Net Blog
To me it is more important their response to how they would solve a problem they know nothing about at the moment, providing they of course know the basics and are of a standard commensurate with the level of the job in question.
"An education isn't how much you have committed to memory, or even how much you know. It's being able to differentiate between what you do know and what you don't." - Anatole France
-
I am trying to come up with a set of questions that will form the initial screening round for all candiates at our company. Any thoughts about questions/concepts that should defintely be known by any programmer?
I always think that the idea of a compiler that compiles another compiler or itself is rather incestuous in a binary way. - Colin Davies My .Net Blog
Location of the Coke machine. Location of the restrooms.
My god, you're a genius! - Jörgen Sigvardsson, The Lounge
-
Personally, I've always thought that interviewers that prepare technical questions ahead of time are missing the total point. You cannot do that and do much justice to the applicant. I mean yeah, you can discuss for loops, recursion, dynamic programming and sorting. Stick to the basics for your canned questions (if you are going to use them, I think canned questions stink). I have yet to be in an interview where the skills in question were not quickly observed or not. You need to look at the applicants resume. I'd go through it carefully. If after going through it carefully you still like the candidate you need to do some more research. If they indicate you can contact present/past employers do it. Don't ask the employers about the candidate ask the employers about the systems the candidate worked on. What challenges had to be overcome in writing the system? What philosophies were used to manage changes, bugs and new code. Start forming an idea in your head of the skills the developer should be bringing to the table after you've done some research. Then go in to the interview with a customized set of questions. Talk about former systems and the challenges. Get a feel for how the developer approaches solving problems. I've always believed a developers answers to solving problems are important but nothing in comparison to how he/she approaches solving problems. Get a feel for that. Get a feel for what it would be like to work with that developer. Most importantly, if your business frequently requires unusual hours or a heavy support burden after hours make that known up front. Developers will piss and moan until the cows come home about support rotation and trouble-shooting. If you make it known in the interview what the expectations are and they still accept the job then you have grounds for saying, "Hey, we told you up front. You accepted the job. Now cork it and get it done." My advice, don't can or script your interviews in an assembly line way. Take the time each applicant really deserves to prepare an interview that is customized for them. They've taken the time to select you as a company. If they are worth anything they have learned as much about your company as they could before coming there. It's your obligation to do the same about them. I think it establishes a healthy relationship from the beginning and it keeps everything in the proper context for an interview. You can talk about design patterns if you wish but if the developers experience has never involved the use of patterns then he/sh
definitely sensible points. surely how someone thinks, if they fit in, and how well their working approach suits what you need is at least as important as their technical knowledge? i have the theory and belief that you can always learn new areas and skills, but if you don't have the right sort of mind set to begin with this will be the biggest problem. zen is the art of being at one with the two'ness
-
definitely sensible points. surely how someone thinks, if they fit in, and how well their working approach suits what you need is at least as important as their technical knowledge? i have the theory and belief that you can always learn new areas and skills, but if you don't have the right sort of mind set to begin with this will be the biggest problem. zen is the art of being at one with the two'ness
feline_dracoform wrote: i have the theory and belief that you can always learn new areas and skills, but if you don't have the right sort of mind set to begin with this will be the biggest problem. I think that about 98% of us would confirm your theory thereby making it a fact. A former boss of mine used to say something to the effect of Aptitude = 200% Attitude. He'd go further to say that with the proper attitude and mind-set a person can be taught almost anything. His concern and his praise was rarely based on aptitude. His reviews always praised and focused on developing attitude. He rewarded very generously for attitude. He had a quip I really liked. "I can improve your aptitude and therefore I should get the raise. Only you can improve your attitude for which I will give you a raise." Good Philosophy and his mileage didn't vary. It was outstanding. To this day he continues to be a mentory. Smart Man he was, strong in the force was he. ;P (Did I really just type that? How embarrassing.)
I know you can't become if you only say what you would have done and you'll miss a million miles of fun." - Len Work hard, play hard. Don't forget who you are and don't forget where you're from. Do all these things well and you won't have to wonder where you are going.
-
Location of the Coke machine. Location of the restrooms.
My god, you're a genius! - Jörgen Sigvardsson, The Lounge
Shog9 wrote: Location of the Coke machine. Location of the restrooms. You obviously have never worked at a large company or you would know... Location of the best and least known parking spots is the knowledge that brings true power. The 3/4 mile daily walk to the car in 100+ degree or sub 20 degree temperatures got really old. Your coke was either boiling or frozen by the time you got to your car. LAME!;P
I know you can't become if you only say what you would have done and you'll miss a million miles of fun." - Len Work hard, play hard. Don't forget who you are and don't forget where you're from. Do all these things well and you won't have to wonder where you are going.