Interview questions - best way to learn the answers
-
c2423 wrote:
My speciality
lol, usually I just say "Learn how I write code - it might not teach you the right way, but at least you've eliminated one option."
-
>And yet I have been using virtual functions for more than 25 years and yet have very, very seldom ever felt a need much less a requirement >to classify a difference specific to "polymorphism." I've been using pencils for 40 years, but that doesn't make me an artist. Whether or not you're a good OO programmer doesn't have much to do with how long you've been "using" virtual functions, it has more to do with how well you understand OO programming. >I have also had many conversations about virtual functions and almost none that mentioned polymorphism. I have had many conversations about gas mileage, and none of them mentioned internal combustion. If I were speaking to my mechanic, I would not expect him to mention internal combustion. If I owned a car shop and were interviewing a mechanic, I would expect him to know what internal combustion was. If I'm speaking to my programming peers, we all know we know polymorphism because of implicit combination of phrases like "virtual", "at runtime", "inheritance", "type conversion", etc. But of course every one of us can "spew it out" at a random moment's notice if necessary if asked the definition. >Myself I understand that my skill in programming is unlikely to translate into communication skills much less people skills. Since the OP mentioned an interview, I'm assuming we're talking about the whole package here - software development in a team environment. Programming is a big part of that, but not all. If your "skill" is unlikely to translate into communication of your ideas, or people skills, you're much less likely to be a successful software developer. >I am quite certain that someone could have an incredible career without know an exact definition for polymorphism The first person to mention "exact definition" in this thread, I think, is you. >not even really knowing what it means and most certainly without the ability to spew it out at a moments notice at the whim of any random >interviewer who thinks term definition is actually objectively significant. "Spew" it out? Getting a little sarcastic, aren't we? "Random" interviewer, or the specific one that can grant you the job at the company you want? I find your arguments a little silly. If you called yourself an OO programmer and yet could not provide me with a basic explanation of polymorphism, you certainly wouldn't get a job at any company I've ever worked at. This is not rocket science, and it's not irrelevent academia or trivia. It's a fundamental concept of OO programming.
Jeff Connelly wrote:
I've been using pencils for 40 years, but that doesn't make me an artist.
Analogy does not apply. A better analogy would be that you are claiming that someone will be a better artist simply because they know that the 'H' in 4H means hardness rather than whether they can choose to use 4H versus 3B effectively.
Jeff Connelly wrote:
Whether or not you're a good OO programmer doesn't have much to do with how long you've been "using" virtual functions, it has more to do with how well you understand OO programming.
Which has nothing to do with term definition.
Jeff Connelly wrote:
I have had many conversations about gas mileage, and none of them mentioned internal combustion.
Analogy does not apply at all.
Jeff Connelly wrote:
If I'm speaking to my programming peers, we all know we know polymorphism because of implicit combination of phrases like "virtual", "at runtime", "inheritance", "type conversion", etc. But of course every one of us can "spew it out" at a random moment's notice if necessary if asked the definition.
Then this should be an easy question for you and for every one in this knowledgable group that you claim knows the definition. Which authorative source would you all immediately point to as the single and only definition for the term?
Jeff Connelly wrote:
Since the OP mentioned an interview, I'm assuming we're talking about the whole package here - software development in a team environment. Programming is a big part of that, but not all. If your "skill" is unlikely to translate into communication of your ideas, or people skills, you're much less likely to be a successful software developer.
Which has nothing to do with interview skills. An analogy back at you... The fact that I can hold a conversation around the water cooler doesn't mean that I am the best candidate or even an adequate candidate to attempt to close a 100 million dollar deal. Or even a 100,000 thousand dollar deal.
Jeff Connelly wrote:
If you called yourself an OO programmer and yet could not provide me with a basic explanation of polymorphism, you certainly wouldn't get a job at any company I've ever worked at.
For the p
-
Ooh, wow. It almost soundslike somebody defending ignorance. I'm sure you can have a fine career and make many dollars without being able to communicate. I'm also pretty sure that people (unless they have a brain injury) can remember the words that name concepts that they understand. Your inability to remember the word probably indicates you don't grasp the concept. I hope you can have a fine career and make many dollars without understanding polymorphism or any other concept. I'm sure there will always be folks around with CS degrees and years of experience who can explain the concepts to you again and again, so that you need never internalize them. You're right. What bearing could understanding software concepts possibly have on writing programs? Only an idiot would interview for such knowledge! As for patterns, the whole point of the design pattern movement is to give patterns names so you can speak about them and remember them. While the patterns existed before they had names, many programmers, even experienced ones, weren't aware of using them. They developed the same things over and over again from first principles. They often made mistakes (google "Double checked locking" or "singleton" for examples). By naming and providing standard descriptions of patterns, you can talk about or code them by reference to a body of written-down knowledge. This is all in the introduction to the GoF book. A lot of less experienced, self-taught developers figure they're so smart they can program rings around their peers even if they have always to work from first principles. A lot of experienced devs know that nobody is that smart.
<blockquote class="FQ"><div class="FQA">Member 2941392 wrote:</div> I hope you can have a fine career and make many dollars without understanding polymorphism or any other concept. I'm sure there will always be folks around with CS degrees and years of experience who can explain the concepts to you </blockquote> At this point I can only suppose that you do not understand the difference between term definition and concept understanding.
Member 2941392 wrote:
As for patterns, the whole point of the design pattern movement is to give patterns names so you can speak about them and remember them. While the patterns existed before they had names, many programmers, even experienced ones, weren't aware of using them. They developed the same things over and over again from first principles. They often made mistakes (google "Double checked locking" or "singleton" for examples). By naming and providing standard descriptions of patterns, you can talk about or code them by reference to a body of written-down knowledge. This is all in the introduction to the GoF book. A lot of less experienced, self-taught developers figure they're so smart they can program rings around their peers even if they have always to work from first principles. A lot of experienced devs know that nobody is that smart.
By definition and even as you mentioned, patterns are not based on term knowledge but on concepts. The fact that I can spew out the intent of Facade doesn't matter if I do not in fact know when to use and when not to use it. However if I do in fact know when to use and not use a Proxy but I mistakenly call it Facade for years and be very successful. And there are in fact interviewers that will mark someone down for failing to give the correct definition while completely ignoring the fact that the definition is correct for another term. And that is a failure on the part of the interviewer.
-
jschell wrote:
That is idealistic.
Yes. Did I set the bar too high?
jschell wrote:
There is no reason to believe that programmers as a group have anything but average interview skills. At best.
He needs to stand out from the other solicitors :) "Programmers as a group" is a very broad public, with a lot of variation in skills. You don't need to encourage someone who loves to code to learn a language or a definition, they'll do that anyway.
I are Troll :suss:
Eddy Vluggen wrote:
You don't need to encourage someone who loves to code to learn a language or a definition, they'll do that anyway.
I see no reason to expect that individuals in that group will learn to excel in communication and interview skills. Since they are in fact spending their time learning other skills. Nor is there any reason to believe that they will come to realize that their knowledge, in terms of human communication, will not match their (presumed) skills in programming. Thus there it is to some degree more likely that they will deem failure to 'correctly' define a term to indicate a failure in skill. While disregarding their own skill failure in correctly determining commnication problems (others as well as their own.)
-
Eddy Vluggen wrote:
You don't need to encourage someone who loves to code to learn a language or a definition, they'll do that anyway.
I see no reason to expect that individuals in that group will learn to excel in communication and interview skills. Since they are in fact spending their time learning other skills. Nor is there any reason to believe that they will come to realize that their knowledge, in terms of human communication, will not match their (presumed) skills in programming. Thus there it is to some degree more likely that they will deem failure to 'correctly' define a term to indicate a failure in skill. While disregarding their own skill failure in correctly determining commnication problems (others as well as their own.)
jschell wrote:
I see no reason to expect that individuals in that group will learn to excel in communication and interview skills.
Depends on the group. If it's a group o' students, in The Netherlands, learning "Information and Communication Science", learning for their masters' - then I expect them to be experts. And not only in intermachine or interhuman communication :)
jschell wrote:
Nor is there any reason to believe that they will come to realize that their knowledge, in terms of human communication, will not match their (presumed) skills in programming.
Your eloquence is hiding the message. I have reason to believe that any person learning a trade will focus on that trade, and I have reasons to believe that they're taught to reflect on their own skills. Yes, I might have put the bar high, but there's a very large pool to choose from. I wouldn't wanna hire someone who goes to this site after his first assignment and posts "Hej, I need medication-managmement app, PlZ SeNd M3 CoD3z".
I are Troll :suss:
-
Jeff Connelly wrote:
I've been using pencils for 40 years, but that doesn't make me an artist.
Analogy does not apply. A better analogy would be that you are claiming that someone will be a better artist simply because they know that the 'H' in 4H means hardness rather than whether they can choose to use 4H versus 3B effectively.
Jeff Connelly wrote:
Whether or not you're a good OO programmer doesn't have much to do with how long you've been "using" virtual functions, it has more to do with how well you understand OO programming.
Which has nothing to do with term definition.
Jeff Connelly wrote:
I have had many conversations about gas mileage, and none of them mentioned internal combustion.
Analogy does not apply at all.
Jeff Connelly wrote:
If I'm speaking to my programming peers, we all know we know polymorphism because of implicit combination of phrases like "virtual", "at runtime", "inheritance", "type conversion", etc. But of course every one of us can "spew it out" at a random moment's notice if necessary if asked the definition.
Then this should be an easy question for you and for every one in this knowledgable group that you claim knows the definition. Which authorative source would you all immediately point to as the single and only definition for the term?
Jeff Connelly wrote:
Since the OP mentioned an interview, I'm assuming we're talking about the whole package here - software development in a team environment. Programming is a big part of that, but not all. If your "skill" is unlikely to translate into communication of your ideas, or people skills, you're much less likely to be a successful software developer.
Which has nothing to do with interview skills. An analogy back at you... The fact that I can hold a conversation around the water cooler doesn't mean that I am the best candidate or even an adequate candidate to attempt to close a 100 million dollar deal. Or even a 100,000 thousand dollar deal.
Jeff Connelly wrote:
If you called yourself an OO programmer and yet could not provide me with a basic explanation of polymorphism, you certainly wouldn't get a job at any company I've ever worked at.
For the p
jschell wrote:
I've been using pencils for 40 years, but that doesn't make me an artist. Analogy does not apply.
That was pretty much my point.
jschell wrote:
I have had many conversations about gas mileage, and none of them mentioned internal combustion. Analogy does not apply at all.
Actually, it does, pretty well.
jschell wrote:
Which authorative source would you all immediately point to as the single and only definition for the term?
No one has mentioned anything about a "single and only definition". That's not the point - at all.
jschell wrote:
Since the OP mentioned an interview, I'm assuming we're talking about the whole package here - software development in a team environment. Programming is a big part of that, but not all. If your "skill" is unlikely to translate into communication of your ideas, or people skills, you're much less likely to be a successful software developer. Which has nothing to do with interview skills.
It has everything to do with interview skills.
jschell wrote:
It's a fundamental concept of OO programming. If you're not into OO, then fine. If you are, then you better know what it means. Wrong.
What I wrote was correct. You're being petty and argumentative.
-
<blockquote class="FQ"><div class="FQA">Member 2941392 wrote:</div> I hope you can have a fine career and make many dollars without understanding polymorphism or any other concept. I'm sure there will always be folks around with CS degrees and years of experience who can explain the concepts to you </blockquote> At this point I can only suppose that you do not understand the difference between term definition and concept understanding.
Member 2941392 wrote:
As for patterns, the whole point of the design pattern movement is to give patterns names so you can speak about them and remember them. While the patterns existed before they had names, many programmers, even experienced ones, weren't aware of using them. They developed the same things over and over again from first principles. They often made mistakes (google "Double checked locking" or "singleton" for examples). By naming and providing standard descriptions of patterns, you can talk about or code them by reference to a body of written-down knowledge. This is all in the introduction to the GoF book. A lot of less experienced, self-taught developers figure they're so smart they can program rings around their peers even if they have always to work from first principles. A lot of experienced devs know that nobody is that smart.
By definition and even as you mentioned, patterns are not based on term knowledge but on concepts. The fact that I can spew out the intent of Facade doesn't matter if I do not in fact know when to use and when not to use it. However if I do in fact know when to use and not use a Proxy but I mistakenly call it Facade for years and be very successful. And there are in fact interviewers that will mark someone down for failing to give the correct definition while completely ignoring the fact that the definition is correct for another term. And that is a failure on the part of the interviewer.
jschell wrote:
And there are in fact interviewers that will mark someone down for failing to give the correct definition while completely ignoring the fact that the definition is correct for another term. And that is a failure on the part of the interviewer.
Wow. All I can say is good luck to all who subscribe to your interview strategy, because they'll need lots of it!
-
jschell wrote:
And there are in fact interviewers that will mark someone down for failing to give the correct definition while completely ignoring the fact that the definition is correct for another term. And that is a failure on the part of the interviewer.
Wow. All I can say is good luck to all who subscribe to your interview strategy, because they'll need lots of it!
Jeff Connelly wrote:
All I can say is good luck to all who subscribe to your interview strategy, because they'll need lots of it!
All I can say is good luck to those that think their adhoc "strategies" for interviewing candidates will lead any more objective results than any other strategy.
-
jschell wrote:
I've been using pencils for 40 years, but that doesn't make me an artist. Analogy does not apply.
That was pretty much my point.
jschell wrote:
I have had many conversations about gas mileage, and none of them mentioned internal combustion. Analogy does not apply at all.
Actually, it does, pretty well.
jschell wrote:
Which authorative source would you all immediately point to as the single and only definition for the term?
No one has mentioned anything about a "single and only definition". That's not the point - at all.
jschell wrote:
Since the OP mentioned an interview, I'm assuming we're talking about the whole package here - software development in a team environment. Programming is a big part of that, but not all. If your "skill" is unlikely to translate into communication of your ideas, or people skills, you're much less likely to be a successful software developer. Which has nothing to do with interview skills.
It has everything to do with interview skills.
jschell wrote:
It's a fundamental concept of OO programming. If you're not into OO, then fine. If you are, then you better know what it means. Wrong.
What I wrote was correct. You're being petty and argumentative.
Jeff Connelly wrote:
No one has mentioned anything about a "single and only definition". That's not the point - at all.
It is the point because some interviewers will in fact be looking for a specific definition.
Jeff Connelly wrote:
It has everything to do with interview skills.
The ability to interact successfully with other team members does not mean that you will be a good interviewer. Sales people interact with people. Managers interact with people. That doesn't mean that a sale person will be a good manager.
Jeff Connelly wrote:
What I wrote was correct.
The fact that it is fundamental concept of an OO language, does not mean that it will fundamentally impact the success of a programmer. There will be good programmers who cannot verbally express what it means. There will be bad programmers that can provide an exact definition.
-
Jeff Connelly wrote:
All I can say is good luck to all who subscribe to your interview strategy, because they'll need lots of it!
All I can say is good luck to those that think their adhoc "strategies" for interviewing candidates will lead any more objective results than any other strategy.
jschell wrote:
All I can say is good luck to those that think their adhoc "strategies" for interviewing candidates will lead any more objective results than any other strategy.
Well, asking an OO programmer to explain what polymorphism, or any other fundamental concept, means would hardly make for an "adhoc strategy". But that's beside the point anyway. The point of this thread was to look at it from the interviewee's point of view. And for any experienced programmers to reply here, it would be irresponsible for us to say anything other than "yes, you should be able to give the meaning of basic OO concepts."
-
Jeff Connelly wrote:
No one has mentioned anything about a "single and only definition". That's not the point - at all.
It is the point because some interviewers will in fact be looking for a specific definition.
Jeff Connelly wrote:
It has everything to do with interview skills.
The ability to interact successfully with other team members does not mean that you will be a good interviewer. Sales people interact with people. Managers interact with people. That doesn't mean that a sale person will be a good manager.
Jeff Connelly wrote:
What I wrote was correct.
The fact that it is fundamental concept of an OO language, does not mean that it will fundamentally impact the success of a programmer. There will be good programmers who cannot verbally express what it means. There will be bad programmers that can provide an exact definition.
jschell wrote:
No one has mentioned anything about a "single and only definition". That's not the point - at all. It is the point because some interviewers will in fact be looking for a specific definition.
Maybe they will and maybe they won't, but you're the only one who's mentioned that so far. You're just trying to argue silly details. The point remains, an interviewee should know what basic OO concepts mean. <blockquote class="FQ"><div class="FQA">jschell wrote:</div>It has everything to do with interview skills. The ability to interact successfully with other team members does not mean that you will be a good interviewer.</blockquote> We were talking primarily about communication. You are leaving things out to suit your need to argue about this, and it's getting tiresome. <blockquote class="FQ"><div class="FQA">jschell wrote:</div>The fact that it is fundamental concept of an OO language, does not mean that it will fundamentally impact the success of a programmer. There will be good programmers who cannot verbally express what it means. There will be bad programmers that can provide an exact definition.</blockquote> Polymorphism is not a fundamental concept of a language, it's a fundamental concept of OO programming and design in general. I know no good OO programmers who cannot express what it means. The bad programmers I've known are confused about it and therefore cannot express what it means. Again, the OP did not mention "exact definition", you did. An exact definition is not the issue, nor are your other additions or changes of the topic to suit your argument.
-
jschell wrote:
No one has mentioned anything about a "single and only definition". That's not the point - at all. It is the point because some interviewers will in fact be looking for a specific definition.
Maybe they will and maybe they won't, but you're the only one who's mentioned that so far. You're just trying to argue silly details. The point remains, an interviewee should know what basic OO concepts mean. <blockquote class="FQ"><div class="FQA">jschell wrote:</div>It has everything to do with interview skills. The ability to interact successfully with other team members does not mean that you will be a good interviewer.</blockquote> We were talking primarily about communication. You are leaving things out to suit your need to argue about this, and it's getting tiresome. <blockquote class="FQ"><div class="FQA">jschell wrote:</div>The fact that it is fundamental concept of an OO language, does not mean that it will fundamentally impact the success of a programmer. There will be good programmers who cannot verbally express what it means. There will be bad programmers that can provide an exact definition.</blockquote> Polymorphism is not a fundamental concept of a language, it's a fundamental concept of OO programming and design in general. I know no good OO programmers who cannot express what it means. The bad programmers I've known are confused about it and therefore cannot express what it means. Again, the OP did not mention "exact definition", you did. An exact definition is not the issue, nor are your other additions or changes of the topic to suit your argument.
Jeff Connelly wrote:
Maybe they will and maybe they won't, but you're the only one who's mentioned that so far. You're just trying to argue silly details. The point remains, an interviewee should know what basic OO concepts mean.
Since I have been in interviews (plural) where it became obvious that the interviewer was looking for very exact answers it certainly seems relevant to me. I am also had conversations with peers that suggested the same as well when they interviewed.
Jeff Connelly wrote:
We were talking primarily about communication. You are leaving things out to suit your need to argue about this, and it's getting tiresome.
Since the topic is about "interview questions" it would seem relevant to me that interviews, and not just communication skills, would be relevant to the discussion. <blockquote class="FQ"><div class="FQA">Jeff Connelly wrote:</div>Polymorphism is not a fundamental concept of a language, it's a fundamental concept of OO programming and design in general. I know no good OO programmers who cannot express what it means. The bad programmers I've known are confused about it and therefore cannot express what it means. Again, the OP did not mention "exact definition", you did. An exact definition is not the issue, nor are your other additions or changes of the topic to suit your argument.</blockquote> Let me restate what I said. 1. Programming skill level does not equate to communication skill level. 2. Communication skill level does not equate to interview skills. But certainly more likely relevant than programming skill. 3. The ability to successfully interview a candidate is based on the ability to recognize that individuals do have different ways of communicating. None of that has anything to do with programming. 4. Some programmers are adamant about specific definitions and terms (you would certainly seem like an example of this.) Attempting to sum ALL of the above together into a interview philosophy without understanding all of the above means that skilled programmers go into interviews often ill-prepared for the interview process. And this is based on both my experience with being interviewed and participating in interviews with other programmers and listening to their discussions afterwards. The fact that I have known many skilled programmers and very few skilled interviewers and even fewer (probably zero) that did anyt
-
Jeff Connelly wrote:
Maybe they will and maybe they won't, but you're the only one who's mentioned that so far. You're just trying to argue silly details. The point remains, an interviewee should know what basic OO concepts mean.
Since I have been in interviews (plural) where it became obvious that the interviewer was looking for very exact answers it certainly seems relevant to me. I am also had conversations with peers that suggested the same as well when they interviewed.
Jeff Connelly wrote:
We were talking primarily about communication. You are leaving things out to suit your need to argue about this, and it's getting tiresome.
Since the topic is about "interview questions" it would seem relevant to me that interviews, and not just communication skills, would be relevant to the discussion. <blockquote class="FQ"><div class="FQA">Jeff Connelly wrote:</div>Polymorphism is not a fundamental concept of a language, it's a fundamental concept of OO programming and design in general. I know no good OO programmers who cannot express what it means. The bad programmers I've known are confused about it and therefore cannot express what it means. Again, the OP did not mention "exact definition", you did. An exact definition is not the issue, nor are your other additions or changes of the topic to suit your argument.</blockquote> Let me restate what I said. 1. Programming skill level does not equate to communication skill level. 2. Communication skill level does not equate to interview skills. But certainly more likely relevant than programming skill. 3. The ability to successfully interview a candidate is based on the ability to recognize that individuals do have different ways of communicating. None of that has anything to do with programming. 4. Some programmers are adamant about specific definitions and terms (you would certainly seem like an example of this.) Attempting to sum ALL of the above together into a interview philosophy without understanding all of the above means that skilled programmers go into interviews often ill-prepared for the interview process. And this is based on both my experience with being interviewed and participating in interviews with other programmers and listening to their discussions afterwards. The fact that I have known many skilled programmers and very few skilled interviewers and even fewer (probably zero) that did anyt
jschell wrote:
Since I have been in interviews (plural) where it became obvious that the interviewer was looking for very exact answers it certainly seems relevant to me.
I'm sure we can all agree that interviewers looking for very exact answers is not a good thing. However, there was nothing in the OP's post that suggested this problem, so I don't know why you insist on going down this path.
jschell wrote:
Communication skill level does not equate to interview skills.
I really don't know what you're talking about. It seems intuitively obvious to me that it pretty much does. That is, knowing it and being able to communicate it.
jschell wrote:
Some programmers are adamant about specific definitions and terms (you would certainly seem like an example of this.)
Again, I really don't know what you're talking about. You keep injecting phrases like "adamant about specific definitions and terms", but you are the only person using such phrases. You seem to be inventing them to bolster your point, whatever it is. I said an OOP candidate should be able to explain what polymorphism means. I don't know anyone who disagrees with that statement. You seem to be on some crusade, the point of which I don't understand, unless the point is merely practicing your contradiction skills.
jschell wrote:
I wouldn't even mind seeing some objective data about any profession that supports that certain questions produce more skilled workers.
I once read a web article about a hiring manager who tried to correlate long term performance and success with how someone performed on their interview. The only correlation he could ever find was that those with the shortest commute to work were the best performers. Of course he had no data on candidates who couldn't explain the meanings of basic concepts related to their areas of supposed expertise. Those candidates were never hired to begin with.
modified on Tuesday, November 16, 2010 4:01 PM
-
Andrew Phillips wrote:
I explained that when refrerring to software the term is the exact opposite of the proper meaning.
Outstanding! I will have to use that, I always had an issue with that word, now I know why!
Andrew Phillips wrote:
BTW, Marc your articles on CP inspired me to write one -
I just scanned it, it's great! Gave you a five, I really like the simplicity of your analogy. One comment though, I was disappointed that you didn't write more about Iterative development, as that is actually the form that I find works best and so therefore I have a deeper personal investment in. :) If you're interested, I could write you up a couple paragraphs on how I found it to work, and its strengths and weaknesses, that you could then add to the article. Marc
Thanks for your reply Marc. Re iterative development - I tried it with little success. However, I keep an open mind. I would love to hear from you if you have time to sen me something.
Andrew Phillips http://www.hexedit.com andrew @ hexedit.com
-
This is probably one of the best threads I've read in a while. I'm glad to know that I'm not the only one out there. I'm a software architect, but I'm also an Infantryman in the Army National Guard. For those of you in foreign countries, this basically means that I am a volunteer military reservist. I've been called up for military duty five times during my programming career. My last deployment was to Iraq. My memory has not been the same since I returned from a one year deployment to Iraq. My programming ability is still there, but I have a hard time some remembering syntax and definitions. I've compensated for this by writing a private blog that functions as a knowledge base. When I do something at work that I know I will have to remember, I write what I did in the blog and save it. Now, this process, or syntax or procedure is in the blog so that I can search for it and find it if I can't remember how I did something. I can't even begin to describe the frustration I encountered when I returned from Iraq and I started interviewing for work. I could not remember the answer basic syntactical questions. I found that drawing my answers on a notepad or a white board before I spoke helped me remember things in interviews sometimes, but many interviewers just found this odd. Usually, other software architects would just look smug as I squirmed in a chair trying to remember how to write a join command in SQL. I knew when to use a join command, but for the life of me, I could not write one from memory. The funny thing is that I could remember high level things just fine. If you asked me a logical programming question, I could describe how I could do something. I could describe how I did things in the past and why. I could tell you the difference between an Interface and an Abstract class and when you would want to use one or the other. I flew through the technical phone screens just fine, but when I was face to face with someone and had to describe how I would access a SQL database, I just couldn't write it without using IntelliSense or Google. My brain just didn't have the words anymore. I'm getting better with remembering syntax. A lot of this comes from me forcing myself to memorize things that I used to be able to remember with ease just a few years ago. The Code Project has helped. I check the Q&A forums once a day to see if I can answer any questions. So no, brother. You are not the only one.
Hm..U are right .Same happens even if we are out of software fields for 3-4 months.. In 4 steps U can come back strong in less than 12 days 1.Only way to brush up,create dummy web project and try to finish in 2-3 days. 2.Then read some interview questions, Create a testpage try to implement that on your page which causes doubts to you. 3.After that create another Dummy webProject for 3-4 days. 4.Then try to answer interview Questions. Apply for job.U will get it in with in 1-2 calls
Mathew M