is something wrong with me ?
-
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.
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 Kreskowiak -
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 Kreskowiak -
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.
Yes, there is something wrong with you. I agree that the questions were dumb but so what? Did you bother to ask any questions? And it is beyond rare that that when you start the job they are all sitting down and pontificating about solid or dry or whatever and that is all that they do. Interviews are a two-way street - you are also interviewing them! You turn a job down because you don't like the location or the rate/salary or the interviewer was rude or whatever, not because you didn't like the questions they picked that day! As a side note I like enthusiasm and passion from a candidate. I don't mind if someone doesn't know what something is as long as they say that they don't know and ask me to explain. I have 5 set questions I always begin with and they are not technical. The first and most important is: What was a project that got you excited and why? The way that they answer that pretty much tells you everything you need to know about a candidate.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
-
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.
-
Yes, there is something wrong with you. I agree that the questions were dumb but so what? Did you bother to ask any questions? And it is beyond rare that that when you start the job they are all sitting down and pontificating about solid or dry or whatever and that is all that they do. Interviews are a two-way street - you are also interviewing them! You turn a job down because you don't like the location or the rate/salary or the interviewer was rude or whatever, not because you didn't like the questions they picked that day! As a side note I like enthusiasm and passion from a candidate. I don't mind if someone doesn't know what something is as long as they say that they don't know and ask me to explain. I have 5 set questions I always begin with and they are not technical. The first and most important is: What was a project that got you excited and why? The way that they answer that pretty much tells you everything you need to know about a candidate.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
What are the other four questions our of interest? The first would of hit a positive note for me.
Simon Lee Shugar (Software Developer) www.simonshugar.co.uk "If something goes by a false name, would it mean that thing is fake? False by nature?" By Gilbert Durandil
-
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.
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.
-
I doubt they even knew THAT version of it! :laugh:
A guide to posting questions on CodeProject
How to debug small programs
Dave Kreskowiak -
Yes, there is something wrong with you. I agree that the questions were dumb but so what? Did you bother to ask any questions? And it is beyond rare that that when you start the job they are all sitting down and pontificating about solid or dry or whatever and that is all that they do. Interviews are a two-way street - you are also interviewing them! You turn a job down because you don't like the location or the rate/salary or the interviewer was rude or whatever, not because you didn't like the questions they picked that day! As a side note I like enthusiasm and passion from a candidate. I don't mind if someone doesn't know what something is as long as they say that they don't know and ask me to explain. I have 5 set questions I always begin with and they are not technical. The first and most important is: What was a project that got you excited and why? The way that they answer that pretty much tells you everything you need to know about a candidate.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
mark merrens wrote:
Yes, there is something wrong with you.
it might be true. But a kind of questions tells you a lot about other person's knowledge and what you are getting your self into.
mark merrens wrote:
Did you bother to ask any questions
yep i did . They asked a question about generations in memory management. i explain them the concept and asked how the question was relevant and his answer was if you know the how generation works you can control how and which object should go to which generations.
-
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.
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 ]
-
mark merrens wrote:
Yes, there is something wrong with you.
it might be true. But a kind of questions tells you a lot about other person's knowledge and what you are getting your self into.
mark merrens wrote:
Did you bother to ask any questions
yep i did . They asked a question about generations in memory management. i explain them the concept and asked how the question was relevant and his answer was if you know the how generation works you can control how and which object should go to which generations.
That's not what you should be asking. At a minimum, ask 3 questions at the end of the interview. Have them written down. Ask them and expect good answers. You might ask "What are you expecting from me in the first 90 days?" or "Can I see where I'll be working?". The former will tell you how organized they might be and/or if they even thought about what you will really be doing and what they want from you, the second will demonstrate an interest but will also show you all the other poor bastards you have to work with. :-)
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
-
mark merrens wrote:
Yes, there is something wrong with you.
it might be true. But a kind of questions tells you a lot about other person's knowledge and what you are getting your self into.
mark merrens wrote:
Did you bother to ask any questions
yep i did . They asked a question about generations in memory management. i explain them the concept and asked how the question was relevant and his answer was if you know the how generation works you can control how and which object should go to which generations.
CS2011 wrote:
you can control how and which object should go to which generations
Mmmhh... I don't know much about managed memory, but I do not see what the point may be. Optimizing code for .NET :-D ?
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus Entropy isn't what it used to.
-
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.
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.
My CP workspace: Incredibly trivial and probably useless code samples[^]
-
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.
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.
-
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.
-
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.
"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.
-
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.
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.
-
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.
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.)
-
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.
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.
Curvature of the Mind now with 3D
-
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.
Curvature of the Mind now with 3D
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.
-
That's not what you should be asking. At a minimum, ask 3 questions at the end of the interview. Have them written down. Ask them and expect good answers. You might ask "What are you expecting from me in the first 90 days?" or "Can I see where I'll be working?". The former will tell you how organized they might be and/or if they even thought about what you will really be doing and what they want from you, the second will demonstrate an interest but will also show you all the other poor bastards you have to work with. :-)
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
I agree completely with Mark here. The point isn't to test the interviewers knowledge on what you think is important technical knowledge at that point in time. Its to test the companies requirements from you. What are your expected goals in the next 3 months? What are their key performance indicators used? What technologies are you expected to be working in or proficient in? What is your expected role within the company? If they are actually part of the SDLC process, then you can ask what their average working day is like. There are a ton of relevant questions that will show them how professional you yourself are, and also give you extremely relevant information in return on whether the company will be a good fit for you. Any monkey can show of technical knowledge, and even learn it. Always remember, don't burn bridges. You don't know who they are connected to or if a few year later you may want a job with them, and their resources department has you red flagged an uncooperative.
