Our new Indie Games subforum is now open for business in G&T. Go and check it out, you might land a code for a free game. If you're developing an indie game and want to post about it, follow these directions. If you don't, he'll break your legs! Hahaha! Seriously though.
Our rules have been updated and given their own forum. Go and look at them! They are nice, and there may be new ones that you didn't know about! Hooray for rules! Hooray for The System! Hooray for Conforming!

Interview Help, Please :) [Software Design]

BoGsBoGs Registered User
edited August 2009 in Help / Advice Forum
So tomorrow I have an interview for a software developer position. I have experience and am looking to move to something better the description is as follows:
* Developing components and web applications using C#, .NET and Microsoft SQL Server
* Designing software using design patterns and best practices
* Writing and reviewing technical specifications
* Troubleshooting, performing problem analysis and fixing bugs
* Software testing

I am good with everything there other then bullet point #2, could anyone please explain that better as there are multiple design patterns in different categories such as Creational, Structural and Behavioural.

Also any other fluff questions that stick in your head you were asked and what you answered with....

I REALLY want this position.

Thanks

BoGs on
"It is the mark of an educated man to teach without a thought." - Aristotle

"Thoughts are a persons imagination going rampid…" - ME :)

Posts

  • SmurphSmurph Registered User regular
    edited August 2009
    Your best best would be to either buy a design pattern book and study the whole thing, or just hit up wikipedia and familiarize yourself with as many as possible. In my experience it usually works like this with design pattern questions:

    Interviewer: Do you know design patterns?
    You: Yes.
    I: What are some of the design patterns you use?
    You: Factory, Visitor, Singleton, ...
    I: Ok, can you explain to me what a Factory is?
    You: Yeah, it's <blahblahblah>

    So have a list of a couple common design patterns that you are ready to explain even if you've never really used them for work.

  • JasconiusJasconius sword criminal Flo-ridaRegistered User regular
    edited August 2009
    BoGs wrote: »
    Creational, Structural and Behavioural

    Those are programming paradigms, not design patterns.

    A design pattern is a style of OOP that adheres to X, Y and Z in terms of the way objects are handled and manipulated.

  • TzyrTzyr Registered User regular
    edited August 2009
    Jasconius wrote: »
    BoGs wrote: »
    Creational, Structural and Behavioural

    Those are programming paradigms, not design patterns.

    A design pattern is a style of OOP that adheres to X, Y and Z in terms of the way objects are handled and manipulated.

    Well, to be fair, the gang of four did split all their design patterns into one of each category listed above.

    But yeah, your best bet is like what was suggested: to either pick up the book I listed above (Design Patterns: Elements of Reusable Object-Oriented Software), another book on design patterns, or just study what is online.

    Design patterns get criticized a lot for a lot of people do not seem to use them properly. For instance, they will either use them too much of the time (you do not need to use a pattern in everything you do), or they won't get used at all. There are a lot of patterns but I would study a handful of them and get to know when you would use them and why.

    "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. "
  • DeebaserDeebaser At the corporate garage sale This is cheap and plentifulRegistered User regular
    edited August 2009
    BoGs wrote: »

    * Designing software using design patterns and best practices

    My general rule of thumb is that any line in a job req that includes the phrase "best practices" is something that the manager and HR really don't understand / care about. "Best practice" usually indicate filler.

  • DeebaserDeebaser At the corporate garage sale This is cheap and plentifulRegistered User regular
    edited August 2009
    Smurph wrote: »
    Your best best would be to either buy a design pattern book and study the whole thing, or just hit up wikipedia and familiarize yourself with as many as possible. In my experience it usually works like this with design pattern questions:

    Interviewer: Do you know design patterns?
    You: Yes.
    I: What are some of the design patterns you use?
    You: Factory, Visitor, Singleton, ...
    I: Ok, can you explain to me what a Factory is?
    You: Yeah, it's <blahblahblah>


    So have a list of a couple common design patterns that you are ready to explain even if you've never really used them for work.

    ^
    ^
    ^
    ^

  • GanluanGanluan Registered User regular
    edited August 2009
    And for the love of god, please make sure you are 100% up to speed on Object Oriented Design. It is fundamentally important yet most of the people I interview have no idea what it entails, let alone how to use/implement it effectively.

    The patterns I've used the most are Singleton, Unit of Work and Factory, all of which are easy to understand and have clear pros and cons.

    Oh, and it's not CS specific but make sure you ask the interviewer plenty of questions:

    How many developers will I work with?
    What bug/issue tracking system do you use?
    What source control system do you use?
    Do you use Team Foundation Server?
    What .NET frameworks will I need to be work with?
    etc.

    If you'd like, I can give some examples of questions I ask when interviewing entry-level .NET developers.

  • BoGsBoGs Registered User
    edited August 2009
    I would love to see the questions you would ask... I am going for Intermediate and am not so familiar with the OOP as my current job doesn't use OOP. I will read up and memorize the ones you mentioned and read more into it tonight.... I am really nerveous :S


    Edit: I remember Object Oriented Design from school use cases and sequence diagrams and such just need to polish up I guess

    "It is the mark of an educated man to teach without a thought." - Aristotle

    "Thoughts are a persons imagination going rampid…" - ME :)
  • GanluanGanluan Registered User regular
    edited August 2009
    I usually tailor the questions to the applicant's skill level (or at the least the skill level they say they have).

    Are you working with .NET in your current job? I would be surprised at any company developing applications without using OOD at least somewhat, unless they're very small-scale apps. I work for a very large corporation so all of our design practices are focused on the enterprise level.

    Here's a few sample questions I ask:

    SQL:
    What is the difference between and inner and outer join? Left outer join vs. right outer join?
    What are primary and foreign keys? Why do you use them?
    What is normalization? Why is it used?
    Why would you use stored procedures instead of inline SQL or vice versa?
    Depending on your expected knowledge, something about indexes, execution plans, etc. but that's more for a DBA

    C#:
    How is memory management handled in C#?
    What is an abstract class?
    What is an interface? How does it compare to an abstract class?
    When would you use a static class?
    What are generic methods? How do you implement your own generic methods/classes?
    What is Reflection? How can it be used?

    General OOD :
    Why is encapsulation important? How would you accomplish it in C#?
    Same question as above for polymorphism and inheritance

    Oh and one other thing: if you don't know what something is, please don't try and bullshit it. It's one thing if you offer what you think it is and aren't quite correct, it's another to quite clearly have no idea yet be unable to admit you don't know. No person knows everything.

    And don't be nervous! Make sure you seem confident and believe you can bring something to the company. The interviewers are just regular people - if I can interview people, they'll let anyone :P

  • BoGsBoGs Registered User
    edited August 2009
    Ganluan wrote: »
    I usually tailor the questions to the applicant's skill level (or at the least the skill level they say they have).

    Are you working with .NET in your current job? I would be surprised at any company developing applications without using OOD at least somewhat, unless they're very small-scale apps. I work for a very large corporation so all of our design practices are focused on the enterprise level.

    Here's a few sample questions I ask:

    SQL:
    What is the difference between and inner and outer join? Left outer join vs. right outer join?
    What are primary and foreign keys? Why do you use them?
    What is normalization? Why is it used?
    Why would you use stored procedures instead of inline SQL or vice versa?
    Depending on your expected knowledge, something about indexes, execution plans, etc. but that's more for a DBA

    C#:
    How is memory management handled in C#?
    What is an abstract class?
    What is an interface? How does it compare to an abstract class?
    When would you use a static class?
    What are generic methods? How do you implement your own generic methods/classes?
    What is Reflection? How can it be used?

    General OOD :
    Why is encapsulation important? How would you accomplish it in C#?
    Same question as above for polymorphism and inheritance

    Oh and one other thing: if you don't know what something is, please don't try and bullshit it. It's one thing if you offer what you think it is and aren't quite correct, it's another to quite clearly have no idea yet be unable to admit you don't know. No person knows everything.

    And don't be nervous! Make sure you seem confident and believe you can bring something to the company. The interviewers are just regular people - if I can interview people, they'll let anyone :P

    WOW this is gold.... I am working as a java developer (going for .net) and am working with older software that was not programmed OOP from the beggining and now it would cost too much to reprogram everything.

    I was able to answer all the sql questions without a doubt.... the C# I knew 20% and the general ood is around the same i have some reading to do.

    Edit:
    what would you recommend to say if they bring alot of questions I do not know, should I mention currently I do not do OOP but am a quick and eager learner. I stress myself out because I want to get something better.

    "It is the mark of an educated man to teach without a thought." - Aristotle

    "Thoughts are a persons imagination going rampid…" - ME :)
  • RiemannLivesRiemannLives Registered User regular
    edited August 2009
    One thing I always look out for when interviewing programmers is people who put stuff on their resume that they don't know. The case where this happens the most is SQL. But if you got all of the questions above off the top of your head you are ahead of just about every person I have ever interviewed that claimed to "know" SQL.

    There is a world of difference between saying "I don't know" and getting caught out trying to bullshit it.

    What you think "makes sense" has nothing to do with reality. It just has to do with your life experience. And your life experience may only be a small smidgen of reality. Possibly even a distorted account of reality at that. So what this means is that, beginning in the 20th century as our means of decoding nature became more and more powerful, we started realizing our common sense is no longer a tool to pass judgment on whether or not a scientific theory is correct. - Neil Degrasse Tyson
  • GanluanGanluan Registered User regular
    edited August 2009
    If they ask you questions you don't know but have heard of, let them know you're familiar with the term but haven't had any experience implementing/using it. Like you said, make sure to mention you're a quick learner and would be willing to get up to speed outside of work hours if necessary.

    If you're familiar with Java, C# should come fairly easily.

Sign In or Register to comment.