|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
You can't do that! You can't ask someone for a solution of the problem because it's a work, but you're not working, you are trying to have a possibilty to give a solution, means you are trying to have the job first and then give a solution! Wow, what did I wrote I don't know, but it's correct..... this is how developer mind working...hahaha...
|
|
|
|
|
CS2011 wrote: what is MMVM
I had one interview that they told me I answered wrong, it turned out their answer was wrong.
I didn't mind not getting a callback.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
BrainiacV wrote: I had one interview that they told me I answered wrong, it turned out their answer was wrong
that's completely different story. i has happened to me many time 
|
|
|
|
|
I'm not sure I agree with the wording of the objection. Theoretical questions are not only fine, they are a good idea. A candidate who has no concept of computer science theory or the abstract concepts involved in software development will produce code that has no governing or organizing principles behind it, and who will make decisions with no awareness of why one choice is better than another.
I don't think it is "theoretical" that is objectionable. It is keyword and buzzword-based interviewing, and arbitrary arcane fact-based interviewing, that is the problem. A lot of technical interviews with non-technical or semi-technical people, or with technical people who haven't thought about what is an effective method of interviewing, go down a sheet asking things like "How many years experience do you have with REST?" "How many years experience do you have with ASP.NET custom controls?" "What is the third option on the file menu in Visual Studio?" This kind of interviewing makes me far less interested in the job, not only because it means the management may not be the greatest, but because everyone they've already hired went through the same, ineffective interview filter and therefore the team I'd be working with is unlikely to be inspiring.
But I've had occasion to ask people about theory, say, to explain the basic ideas that make up object-oriented programming, and it can sometimes very quickly take someone who looks good on paper and discover the reality. You have to do that kind of thing in order to get a sense of whether the person understands what the acronyms he has pasted onto his resume actually mean...because there are as many candidates out there who are nothing more than a collection of buzzwords and keywords as there are hiring managers who are the same.
|
|
|
|
|
Trajan McGill wrote: . A candidate who has no concept of computer science theory or the abstract concepts involved in software development will produce code that has no governing or organizing principles behind it, and who will make decisions with no awareness of why one choice is better than another.
Well i would disagree with this. Even i know what is MVVM there is no way i use it until i have some exp with it. To judge a person if he can make a informed decision about which pattern to use and which to avoid you need to ask practical question. if you ask him tell me what is factory pattern and what is command patterns or what is DI you can never judge if he can do a good design. Best way to judge a if someone has good knowledge give me a problem and ask for a design and see how good the design is and if is following Factory/DI/MVVM and so on where it's required.
|
|
|
|
|
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.
|
|
|
|
|
CS2011 wrote: and all the question he asked was theoretical like what is MMVM, What is solid principal and DI... 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
Since I don't interview candidates as a full time job, I keep a list of interview questions that I pull from. Some questions are theoretical, some not. They don't really reflect how the team works together, but are tools for me to assess how well the candidate will fit in and how much they might need to pick up. Trying to judge how my team works by the questions I ask would be a mistake. If you want to know, ask me. If I'm only asking theoretical questions, asking why is a fair question from a candidate.
Are you sure you didn't reject that offer because of an incorrect assumption about how the team works that you based simply on which questions they asked to assess your knowledge and fit?
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
patbob wrote: Are you sure you didn't reject that offer because of an incorrect assumption about how the team works that you based simply on which questions they asked to assess your knowledge and fit?
Well you might be correct.
Some theory and some not i can understand but when every single question asked is theoretical..Well that's different story. In my personal experience person taking interview will be your boos (most of the case if not all and again in my experience) and i really didn't wanted to report to someone who is more interested in theory rather then checking out if a personal has some real problem solving skills.
|
|
|
|
|
I take it there weren't other members of the interview team that assessed your problem solving skills?
In some of the interview teams I've been on, we split up what we questioned a candidate about to get better coverage in the available time. If all the technical people quizzed you about theoretical knowledge, then yes, that would be a bad sign .
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Well, if you ask me a Software Architect is someone that will deal with a high level of abstraction so understanding the principles and theory behind the code it's a must, although a pure theory interview it's not very productive.
|
|
|
|
|
There was a time when they used to ask:
1) What appeals to you more? Having a clean desk or looking at a pretty girl?
2) How much do you drink per week?
...
They used "industrial psychologists" and not HR / IT interviewer types.
(Got the job).
|
|
|
|
|
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.
|
|
|
|
|
...but...what happens if you give modern kids old technology?
Kids react to...the Walkman[^]
Make me feel old. 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Nauseatingly *ahem* confident children.
Though it is a worry the older ones don't seem to know how to use headphones.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
