|
CS2011 wrote: Any one who has access to internet can tell you the definitions
It gets worse when they believe they actually understand the concepts 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
No what's worse is when the interviewer ALSO got the questions and definitions from the same source on the internet. Actually had it happen once. Looking back now, I could have probably told them an Array was what Dark Helmet used on people's jewels when they went over his helmet. [^] Or could have gotten away with defining Friend Classes as the parts of code written with the Paired Programming technique.
Someone mentioned knowing between Private and Public.. That's easy! Private is the code I am not willing to share with anyone.. Public is the code I got off CodeProject 
|
|
|
|
|
I wouldn't let stuff like that put you off. It's just the sort of rubbish people ask in interviews. Design patterns is a favourite. Usually can you just name a few which is probably the extent of the knowledge the interviewers have.
Far more important is whether they come across as 'normal' people (provided you're normal yourself of course).
Regards,
Rob Philpott.
|
|
|
|
|
Hi. Im a software developer, who was going to study HR or Psychology, and still studies some HR stuff at my free time. SO, I can "see" I.T. recruiting, both, from I.T. Technical view, and, Psychologycal H.R. point of view.
I think you are wrong, because, even if they could do a better job at interviewing, you DID knew the answer, and you DID could help them to change they way they work & interview people.
Now, Im agree that a lot of people can fake their skills at interviews, with access to internet. But, the opposite is also true, its very difficult these days to pass an evaluation, without the internet, even if you have years of proven experience.
I have been tested with several theorical tests, and failed them, yet, when the HR / IT people give me a PC, and ask me to do some test, I usually passed. Most of those theorical questions, that I missed, doesn't mean I care, or I never study them. It's just that there is too much information these days, and its kind of difficult to remember all the details at a job interview.
I believe that experience, also matches a lot of others job prospects.
I do believe, that HR process, these days, in many companies, is doomed, for several reasons. Just doing a plain theorical interview, as your case, is an example. Skipping a practical technical test, because there is too many people to with an interview, is another. Supporting recruitment with a: Calculus, Algebra, Abstract Math evaluation, to I.T. because they require to have strong Math skills, is another common HR error. And, so on.
Cheers.
umlcat [ mail dot uml cat at g mail dot com ]
modified 23-Apr-14 12:18pm.
|
|
|
|
|
IMHO, wrong decision. You cannot generalize group based on individual. Of course, they all may be same but that is not right.
I would have stated in the interview up front that I, personally, believe that we should be focusing on real World problems that I may have to solve during the job rather than knowing definitions.
I have shared my opinions many a times in an interview and was rejected. No, I do not quote that as a reason but it is really awesome coincidence. But I do feel it is not really a good thing to do in interview. Never piss off the interviewer.
I have had privilege to taking interviews as well and I found certain people with all kinds of MS certifications not being able to tell solutions to basic real World problems. For instance, I once asked, "Well, we have plenty of extension methods with LINQ that make is easy to iterate as far as lines of code is concerned. We also have TPL in .Net 4.0 that enables parallel processing. If possible, what do you think we can use if we are to use .Net framework 2.0 and achieve the same? If not, then what do you think would be an optimal way to get close?"
Hence, I tend to stay away from definitions as much as possible. Instead, I try and give small requirement that actually asks for the person to actually use the definition that is readily available on web.
|
|
|
|
|
d@nish wrote: I would have stated in the interview up front that I, personally, believe that we should be focusing on real World problems that I may have to solve during the job rather than knowing definitions.
Well i did that and the answer which i got was hilarious. After 15-20 mins of theory i told them "I am more practical kind of guy and i think it will be better if you ask more real world related problem rather then asking definitions. Like last question about generations of objects. There is no way you can control that so why that is impotent?." His reply "If you the generation you can control which object should go to which generation" and i was like WTF..and the interview continued the same way.
|
|
|
|
|
That was funny. You could have said, "Your generation objectifies everything and dictates terms. Want to take it outside?". Would have been some experience to cherish.
One of the questions that always baffles me is when I am asked about garbage collection and generations and how and when object moves through them. Now, I have no clue as to how exactly GC does it. And primarily, I do not care as I mostly write rather simpler application that do not care about every single nanosecond and every bit. If were to write application of that sort, I would use C or C++ or any other real low level programming language. But well, I am fairly straightforward with my views and I do not filter them. It often comes across as arrogance or rude behavior for many. I am just not going to change an opinion if someone cannot provide a valid justification to do so.
|
|
|
|
|
CS2011 wrote: I always had problem with theoretical questions in interview.
The fact that someone is technically competent doesn't mean that they can competently communicate. And more significantly it doesn't mean that they can ask questions that objectively judge skills.
Some people recognize that but, probably and unfortunately, most do not. Sort of sad to see a technical interviewer fumble about because they suddenly realized that the interviewee knows vastly more than the interviewer and perhaps even knows a more correct answer.
Of course it is even worse when a technical interviewer wanders off into matters that are not technical and which may not even be legally discussed in an interview.
|
|
|
|
|
Not having interviewed in 10 years; can't you pull out your iphone and answer the question?
|
|
|
|
|
"The definition" can say a lot about you. I had interviewed two times before and I asked theoretical questions. It is easy to recognize answer by the book. Definitions learn by heart does not make much sense to the learner.
Definitions used simple words are just reproduction of what interviewee understands (best case, happened to me twice).
Definitions with more complicated words (but self reproduced and not learned by heart) may mean more experience in that area. (happened once).
The shorter it takes to answer, the more recently interviewee used that theory before.
Not knowing the theory itself can also tell how the interviewee acts when it does not know how to do something. If (s)he admits and seeks help it is suitable for team work. If (s)he tries to simulate knowledge, it'll probably simulate work. If (s)he admits, but don't seek help (s)he is probably prefer to work alone.
It is amazing how much information you can get for someone by just answering a simple theoretical question.
|
|
|
|
|
Yes there is something wrong with you 
What's wrong with being asked to explain what MVVM is if you're going to work in a job where MVVM is being used?
They're looking to see if you understand the principals, not just if you can memorise definitions.
If the team is using MVVM with DI and asked you to solve a problem, you could probably solve it quite well using winforms and binding to datatables - but that wouldn't show that that you could work in their environment.
Being a good dev isn't just about coding solutions to problems, it's much more than that.
|
|
|
|
|
_Maxxx_ wrote: What's wrong with being asked to explain what MVVM is if you're going to work in a job where MVVM is being used?
Nothing wrong with asking what is MVVM. But i prefer in which case you will go for MVVM. First one anyone can answer second one not if have not actually worked with it. i would asked first question if a person has say 1 or 2 yrs of exp defiantly not when he has 7+ yrs of exp
|
|
|
|
|
I don't understand why you think anyone can answer what is MVVm while people who haven't used DI won't know what it is? why should people who haven't used MVVM know what it is?
Also you assume that everyone's CV is honest. Yours might say you have 7 years experience - but what have you been doing ReALLY for 7 years? Maybe working on some VB with MS Access project?
If the job requires MVVM, DI etc. then surely asking what your understanding of them is is quite legitimate? They arent's aying that if you don't know you won't get the job, just asking what your knowledge is. Maybe if you said "I never used DI" they'd set up some training for you.
|
|
|
|
|
_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 entirely disagree. except for the most basic programming positions, the ability to write code is way down on my list of requirements - a good developer needs to have a good understanding of WHY certain things are done in certain ways, and have a good understanding of the shortcomings in their experience and knowledge.
Understanding what MVVM is, why it can be a good pattern etc. without ever having used it can be a far better indicator of someone who would be useful than having someone who can write some MVVM code without understanding.
The former tends to be a thinker, will look at alternatives and not just stick to doing things the way they have learned because, well, that's the way they learned, whereas the latter will more likely churn out the same stuff and not think outside the square.
Both types have their uses - the latter as cannon fodder, the former as generals.
as a real example.
given
.Where(predicate).FirstOrDefault();
vs
.FirstOrDefault(predicate);
Any dev could probably have a good guess at what they did - even if they had never seen either construct before.
Some devs would tell you that you should use the 2nd version over the 1st version.
The dev i want is the one who tells you which version they would use, and why.
it's not necessary that they concur with my personal choice (the first, incidentally) but that they can support their decision beyond 'that's just how I do it'.
I['m waffling -a sure sign I need another beer.
|
|
|
|
|
_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.
?  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 sh*t 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.
|
|
|
|
|
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
|
|
|
|
|
I had an interview where they asked me to explain MVC. I said "Isn't MVVM the latest thing?"
Then there was the time time they asked "How would you reverse a string in C?" I went up to the white board and wrote "strrev". Got a good laugh. (Then I wrote the algorithm.)
|
|
|
|
|
That reminds me of an interview I had last time I was out looking.
Them: how would you reverse a string?
Me: I'd use the standard functionality already in the library. Why would I rewrite it? It's already provided, and the people who wrote that are probably better at developing software than me.
Them: What if it wasn't there.
Me: Well, ok, blah blah blah about null-checking, maybe making it an extension method, etc, etc.
I got home and phoned the headhunter, saying I didn't think it had gone too well. Twenty minutes later, she called back, saying they loved me, and wondering if I could come back that afternoon to meet with the CTO or VP or some such.
I ended up not taking that position; I didn't think it was as good a fit for me personality-wise as where I ended up. But, one shouldn't judge an organization by the kinds of questions they ask, necessarily. They're just trying to get some kind of insight into your analysis/thought process.
|
|
|
|
|
I think that's definitely a huge warning sign. If the interview is too simplistic, there is a good chance that you can get stuck on a system with tons of buggy poorly written code.
I would definitely make sure I asked about their development process, what they consider quality code and how they maintain that level of code in their system, etc. I'd also ask them to describe the best and worst features of their code base. Also, ask about improvements/refactorings driven completely by the development team. How do they make sure their system stays up to date with best practices? What kind if training has the team received? How much control do developers get over their systems and how easy is it to get the plugins that you need?
I think that's a good start.
|
|
|
|
|
It takes me less than five minutes to decide whether to hire someone or not. Several studies suggest that the hiring decision is actually made in the first 20 seconds. (Then it takes weeks to get it through management and HR.) It's pretty much the same when I'm being interviewed, a process I'm doing right now. Once I decide I do want to work at a place, I'll engage in a longer conversation (which often makes me more enthusiastic for the job), but it's not really needed.
|
|
|
|
|
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 
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.
Same goes for me.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
