is something wrong with me ?
-
_Maxxx_ wrote:
why should people who haven't used MVVM know what it is?
Well mainly 'coz of this https://www.google.co.in/?gfe_rd=cr&ei=je1ZU-jcOo3V8gf17YGwBw#q=what+is+mvvm[^] How people will start having problem until they have some real exp if you ask which situation do you think we should go for MVVM and which situation do you think we should avoid it ?
_Maxxx_ wrote:
Also you assume that everyone's CV is honest.
direct opposite of it. people can fake theoretical knowledge but not practical.
_Maxxx_ wrote:
If the job requires MVVM, DI etc. then surely asking what your understanding of them is is quite legitimate?
understanding ? Yep. definitions ? Not so much
_Maxxx_ wrote:
They arent's aying that if you don't know you won't get the job,
i never said i didn't know. infarct i did answer the question. IMHO it's not a good way to judge a skill of programer by asking theoretical question. You should always ask more practical question (like where you can judge his problem solving skills)
CS2011 wrote:
Well mainly 'coz of this https://www.google.co.in/?gfe_rd=cr&ei=je1ZU-jcOo3V8gf17YGwBw#q=what+is+mvvm[^]
Don't know about you, but I've never been to an interview where they allowed you to google stuff during the interview!
CS2011 wrote:
f you ask which situation do you think we should go for MVVM and which situation do you think we should avoid it ?
well, any decent interviewer and interviewee will begin a dialog. if the interviewer asks "what is MVVM" and you reply "Model View ViewModel" then shut up, it's all a bit pointless. depending on the position, perhaps they have existing MVVM projects on which they want someone to work. Pointless asking you when you wouldn't use MVVM - better to make sure you understand what it is.
CS2011 wrote:
people can fake theoretical knowledge but not practical.
You can lie or exaggerate practical knowledge - I have interviewed people who have told me about their wide experience in xyz technology, but when asked to explain the technology have failed - giving textbook definitions rather than explaining how they have used it (or not) - so they have faked practical and theoretical knowledge. Remember, just because you know that you know something, doesn't mean the interviewer knows. and the way they find out it by asking questions.
CS2011 wrote:
understanding ? Yep. definitions ? Not so much
Are you telling me that they asked "Please define what is meant by MVVM" with no expectation of beginning a discourse?
CS2011 wrote:
never said i didn't know.
And I never said you didn't know. I said that they weren't saying that if you didn't know you wouldn't get the job. interviews aren't about asking questions with correct answers, they are about getting to know someone's abilities (can they do the job) and personality(do we want them to work here) quickly.
CS2011 wrote:
it's not a good way to judge a skill of programer by asking theoretical question.
I entire
-
Well, I have different sort of problems with those kind of questions: I don't memorize definitions. I've been asked what SOLID is, and damn it, I always get stuck in the L :doh: The point is... I apply all SOLID concepts on my daily work, but it really gets in my nerves when someone asks me to define the principles. This applies to a lot of things and I believe I failed some interviews because I can't memorize things well. It's very hard to be asked questions that test my problem solving capabilities (which I excel at), but I wouldn't turn down a job because of the questions the interviewer asked. I'm more concerned about what type of work I will be performing, the environment and the earnings.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
Likewise. And if the interviewer here was genuinely just asking for a definition, then they're dumb. I was asked at an interview about 3rd level normalisation in a Db. I answered (truthfully) that I have never had to normalise a database I have designed, as normalisation is as obvious to me as putting a full stop at the end of a sentence. I can probably remember some of the rules of normalisation, but I don't need to know them. It's a bit like asking in a driving test how far behind a car should you be if you are both driving at 60KPH. I have no idea of the actual recommended distance - I just know when I'm too close.
-
CS2011 wrote:
Well mainly 'coz of this https://www.google.co.in/?gfe_rd=cr&ei=je1ZU-jcOo3V8gf17YGwBw#q=what+is+mvvm[^]
Don't know about you, but I've never been to an interview where they allowed you to google stuff during the interview!
CS2011 wrote:
f you ask which situation do you think we should go for MVVM and which situation do you think we should avoid it ?
well, any decent interviewer and interviewee will begin a dialog. if the interviewer asks "what is MVVM" and you reply "Model View ViewModel" then shut up, it's all a bit pointless. depending on the position, perhaps they have existing MVVM projects on which they want someone to work. Pointless asking you when you wouldn't use MVVM - better to make sure you understand what it is.
CS2011 wrote:
people can fake theoretical knowledge but not practical.
You can lie or exaggerate practical knowledge - I have interviewed people who have told me about their wide experience in xyz technology, but when asked to explain the technology have failed - giving textbook definitions rather than explaining how they have used it (or not) - so they have faked practical and theoretical knowledge. Remember, just because you know that you know something, doesn't mean the interviewer knows. and the way they find out it by asking questions.
CS2011 wrote:
understanding ? Yep. definitions ? Not so much
Are you telling me that they asked "Please define what is meant by MVVM" with no expectation of beginning a discourse?
CS2011 wrote:
never said i didn't know.
And I never said you didn't know. I said that they weren't saying that if you didn't know you wouldn't get the job. interviews aren't about asking questions with correct answers, they are about getting to know someone's abilities (can they do the job) and personality(do we want them to work here) quickly.
CS2011 wrote:
it's not a good way to judge a skill of programer by asking theoretical question.
I entire
_Maxxx_ wrote:
Don't know about you, but I've never been to an interview where they allowed you to google stuff during the interview!
How about a night before the interview. You get the JD in advance don't you ?
_Maxxx_ wrote:
depending on the position
For a SW architect i think it's impotent to know when to use a pattern and when NOT to use a pattern. Knowledge of theory will not help you in this.
_Maxxx_ wrote:
but when asked to explain the technology have failed - giving textbook definitions rather than explaining how they have used it.This is called practical knowledge (or not) -
As you statement says. he was not able to fake practical knowledge ( he tried but failed 'coz he was not able to explain)
_Maxxx_ wrote:
Are you telling me that they asked "Please define what is meant by MVVM" with no expectation of beginning a discourse?
Yes. Kind of. They were more interested in just tell me What MVVM is
_Maxxx_ wrote:
good understanding of WHY certain things are done in certain ways, and have a good understanding of the shortcomings in their experience and knowledge.
and how does you get to know that ? By reading books to writing actual code ?
_Maxxx_ wrote:
someone who can write some MVVM code without understanding.
Well i have not met someone who can write a good code based on MVVM without proper understanding.(But again i am talking about people i work with)
_Maxxx_ wrote:
The former tends to be a thinker, will look at alternatives and not just stick to doing things the way they have learned because
that again comes with practical knowledge not by knowing theory and definitions
_Maxxx_ wrote:
The dev i want is the one who tells you which version they would use, and why.
and surely the will be able to answer that by reading it on MSDN. But internal working...that's a different ball game :)
-
_Maxxx_ wrote:
Don't know about you, but I've never been to an interview where they allowed you to google stuff during the interview!
How about a night before the interview. You get the JD in advance don't you ?
_Maxxx_ wrote:
depending on the position
For a SW architect i think it's impotent to know when to use a pattern and when NOT to use a pattern. Knowledge of theory will not help you in this.
_Maxxx_ wrote:
but when asked to explain the technology have failed - giving textbook definitions rather than explaining how they have used it.This is called practical knowledge (or not) -
As you statement says. he was not able to fake practical knowledge ( he tried but failed 'coz he was not able to explain)
_Maxxx_ wrote:
Are you telling me that they asked "Please define what is meant by MVVM" with no expectation of beginning a discourse?
Yes. Kind of. They were more interested in just tell me What MVVM is
_Maxxx_ wrote:
good understanding of WHY certain things are done in certain ways, and have a good understanding of the shortcomings in their experience and knowledge.
and how does you get to know that ? By reading books to writing actual code ?
_Maxxx_ wrote:
someone who can write some MVVM code without understanding.
Well i have not met someone who can write a good code based on MVVM without proper understanding.(But again i am talking about people i work with)
_Maxxx_ wrote:
The former tends to be a thinker, will look at alternatives and not just stick to doing things the way they have learned because
that again comes with practical knowledge not by knowing theory and definitions
_Maxxx_ wrote:
The dev i want is the one who tells you which version they would use, and why.
and surely the will be able to answer that by reading it on MSDN. But internal working...that's a different ball game :)
CS2011 wrote:
How about a night before the interview. You get the JD in advance don't you ?
Sure. And I have previously looked stuff up that i wasn't familiar with for an interview, and when asked, explained that I knew what it was but didn't have experience of it - explained my understanding, anyway.
CS2011 wrote:
Knowledge of theory will not help you in this.
? :confused: Of course it will. Part of the theoretical knowledge about something is about when it is useful, and (more importantly) why.
CS2011 wrote:
and how does you get to know that ? By reading books to writing actual code ?
well, both.
CS2011 wrote:
Well i have not met someone who can write a good code based on MVVM without proper understanding.(But again i am talking about people i work with)
Well, who said anything about good code? I work on an mvvm system where a lot of devs have been through the company, and much of the code is completely shit because they didn't understand the principals, so just copy/pasted code, or did things how they would have done in a non MVVM environment. These are people, I think, who had much practical experience of various thechnologies - but unfortunately nobody asked them to explain MVVM at the interview ;)
CS2011 wrote:
not by knowing theory and definitions
Ah, now, definitions, I'm with you there. No need to know the name of something as long as you can communicate with your peers. But theory? yes you do need to understand the theory.
CS2011 wrote:
and surely the will be able to answer that by reading it on MSDN.
sure - and if they have read on MSDN and understood and retained the knowledge, then that knowledge is useful. And that's why the interview needs to be a conversation not a monologue.
-
CS2011 wrote:
How about a night before the interview. You get the JD in advance don't you ?
Sure. And I have previously looked stuff up that i wasn't familiar with for an interview, and when asked, explained that I knew what it was but didn't have experience of it - explained my understanding, anyway.
CS2011 wrote:
Knowledge of theory will not help you in this.
? :confused: Of course it will. Part of the theoretical knowledge about something is about when it is useful, and (more importantly) why.
CS2011 wrote:
and how does you get to know that ? By reading books to writing actual code ?
well, both.
CS2011 wrote:
Well i have not met someone who can write a good code based on MVVM without proper understanding.(But again i am talking about people i work with)
Well, who said anything about good code? I work on an mvvm system where a lot of devs have been through the company, and much of the code is completely shit because they didn't understand the principals, so just copy/pasted code, or did things how they would have done in a non MVVM environment. These are people, I think, who had much practical experience of various thechnologies - but unfortunately nobody asked them to explain MVVM at the interview ;)
CS2011 wrote:
not by knowing theory and definitions
Ah, now, definitions, I'm with you there. No need to know the name of something as long as you can communicate with your peers. But theory? yes you do need to understand the theory.
CS2011 wrote:
and surely the will be able to answer that by reading it on MSDN.
sure - and if they have read on MSDN and understood and retained the knowledge, then that knowledge is useful. And that's why the interview needs to be a conversation not a monologue.
_Maxxx_ wrote:
Part of the theoretical knowledge about something
Can you tell me what exactly do you mean by theoretical knowledge.
_Maxxx_ wrote:
well, both.
reading books to get real life problem solving skills and i wonder why company looks for experienced guys when someone who had finished a book on C# can do the same level of job with same efficiency and quality.
_Maxxx_ wrote:
unfortunately nobody asked them to explain MVVM at the interview
he might have answered What is MVVM same way by reading a night before :)
_Maxxx_ wrote:
yes you do need to understand the theory.
And you will need to do some practical to understand the theory otherwise it's no good. Let me give a simple example. if you ask some one what is DI. and he gave to the correct answer that DI is this and this and these are the way using which you can implement DI. Does it mean that person will be able to do that in real life and knows where this actually fit ? he might or he might not can't be sure. Now ask someone i have class A,B and C,i need to access objects of class b and c from a. please explain how you are going to do that and bingo you know if this guy know DI or not.
-
I always had problem with theoretical questions in interview. recently i was interviewed for a SW Architect position and all the question he asked was theoretical like what is MMVM, What is solid principal and DI. I did answer the question and got the offer but i rejected it saying i was not OK with the way interview went and kind of question i was asked and would not like to work with a team like that. My thinking is if you want to know if someone knows thing give him a problem ask to design a solution. Any one who has access to internet can tell you the definitions.
There is nothing wrong with you. You felt that the questions did not correspond to your way of thinking and your way of looking at the job and of approaching the situations at hand. Thus, you had to reject the job. Most interview questions have long been *extremely* inadequate at judging prospective employers, something that Microsoft and Google have now began to realize and change. I wish that everyone was like you. You disagree with something and you stand up to it with courage and state your opinion. No, there is nothing wrong with you. What you have is integrity. There is nothing wrong with that.
-
Likewise. And if the interviewer here was genuinely just asking for a definition, then they're dumb. I was asked at an interview about 3rd level normalisation in a Db. I answered (truthfully) that I have never had to normalise a database I have designed, as normalisation is as obvious to me as putting a full stop at the end of a sentence. I can probably remember some of the rules of normalisation, but I don't need to know them. It's a bit like asking in a driving test how far behind a car should you be if you are both driving at 60KPH. I have no idea of the actual recommended distance - I just know when I'm too close.
_Maxxx_ wrote:
normalisation is as obvious to me as putting a full stop at the end of a sentence.
Awesome response
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
_Maxxx_ wrote:
Part of the theoretical knowledge about something
Can you tell me what exactly do you mean by theoretical knowledge.
_Maxxx_ wrote:
well, both.
reading books to get real life problem solving skills and i wonder why company looks for experienced guys when someone who had finished a book on C# can do the same level of job with same efficiency and quality.
_Maxxx_ wrote:
unfortunately nobody asked them to explain MVVM at the interview
he might have answered What is MVVM same way by reading a night before :)
_Maxxx_ wrote:
yes you do need to understand the theory.
And you will need to do some practical to understand the theory otherwise it's no good. Let me give a simple example. if you ask some one what is DI. and he gave to the correct answer that DI is this and this and these are the way using which you can implement DI. Does it mean that person will be able to do that in real life and knows where this actually fit ? he might or he might not can't be sure. Now ask someone i have class A,B and C,i need to access objects of class b and c from a. please explain how you are going to do that and bingo you know if this guy know DI or not.
CS2011 wrote:
Can you tell me what exactly do you mean by theoretical knowledge.
Knowledge that is not practical - ie something you have learned about but not used in practice. For example, I know a great deal about knockoutJs but have only tinkered with it - I have much theoretical knowledge and little practical knowledge.
CS2011 wrote:
i wonder why company looks for experienced guys when someone who had finished a book on C# can do the same level of job with same efficiency and quality.
now you're being childish and silly. Of course they cannot. But, someone who has studied, and understood, a subject but not yet put the subject into practice can be far better than someone who has simply copy/pasted code without understanding,
CS2011 wrote:
he might have answered What is MVVM same way by reading a night before
Again we come back to this; if the interviewer simply asks for a list of definitions, then you're right. what interviewers do, though, is to engage you in a conversation - what do you understand by MVVM? Interesting - are you currently using it? Oh! what framework do you use? Oh! we use xyz - do you have any exposure to that? why did you use that framework? and so on.
CS2011 wrote:
you know if this guy know DI or not.
No, you don't. You don't have to use DI to do that, for starters. And, say, the interviewees answer was to pass an instance of the class to the constructor; does that mean they know DI, understand why it is used, understand when it is good or bad, understand the difference between passing concrete classes and interface references? Bottom line. I would rather employ someone with good understanding and less practical hands-on than the other way around. there are many crap programmers out there, who can knock out code that is ill thought out, poorly constructed and not well maintainable - but they use MVVM, DI etc. etc. those that understand their subject, don't tend to write such crap code, because they have an in-depth understanding of the whys and wherefores
-
When conducting an interview, it seems like I just about never get to questions anywhere close to that. I have a hard enough time getting interviewee's to tell me the difference between "public" and "private"!
A guide to posting questions on CodeProject
How to debug small programs
Dave KreskowiakEasy: Everyone can access public, but only class members and the NSA can access private ;P
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
Well, I have different sort of problems with those kind of questions: I don't memorize definitions. I've been asked what SOLID is, and damn it, I always get stuck in the L :doh: The point is... I apply all SOLID concepts on my daily work, but it really gets in my nerves when someone asks me to define the principles. This applies to a lot of things and I believe I failed some interviews because I can't memorize things well. It's very hard to be asked questions that test my problem solving capabilities (which I excel at), but I wouldn't turn down a job because of the questions the interviewer asked. I'm more concerned about what type of work I will be performing, the environment and the earnings.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
Fabio Franco wrote:
I don't memorize definitions.
Agreed. I've been using most of the GoF Design Patterns long before the book was written. Why should I learn the definitions some people made up aound the stuff I'd been doing for years? Am I a worse programmer because I don't know what Gamma et al consider to be the difference between a factory and an abstract factory? :-\ I've been using that stuff. I know how it works. Why should I care how to call it? Knowing definitions doesn't proof skill, it only proofs that you're good at Knowing definitions.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
You're actually disagreeing with the inverse of what I said. You're right, understanding a concept doesn't necessarily mean one knows the details as they work in practice, but not understanding a concept definitely means one doesn't know the details as they work in practice. If you can't even explain the idea of MVVM, there's no point in asking you to show it in practice. You also can get some feel for whether the person has truly applied these concepts by their answers. Do the answers sound like recited, memorized dictionary definitions? Do they sound like a vague conceptual awareness? Does the person seem to have familiarity with the messiness that one encounters when taking pure-sounding ideas and putting them into practice? But there's more to it than that. There are plenty of developers who can slap together things that work, more or less. There are a zillion programmers who have tons of technical knowledge at the detail level, without having any real conception of the higher, more abstract levels. I encounter their code all the time, and it has no forethought, no theory or philosophy, and no maintainability. Where they use patterns or concepts, they invoke them like magical incantations, rather than with understanding. An interview process should definitely look for this weakness. I'd rather have a person who thinks well and has never used the tool, language, or even specific programming patterns in question than one who cranks out cargo cult code based on a copy-and-paste-level understanding of MVVM or whatever. The best way to examine this involves a variety of things going on in the interview process, and I agree it involves talking through actual problems and exploring their thought processes, but that is a part of asking about theory, it isn't a replacement for it.
The question is: can the interviewee know nothing of the concepts of MVVM just because he doesn't know the definition that you are asking about? I've been using design patterns for many years, before Gamme et al even wrote that book! Just because at the time I couldn't answer what a bridge or factory pattern was didn't mean that I I didn't know and firmly understand the concepts! It's an entirely different thing if you ask about some keywords that are familiar to you, or the concepts behind it! It's possible that the person you're asking is not familiar with that keyword, but knows more about the concepts than you ever will.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]