Interview Help, Please :) [Software Design]

BoGs · August 2009

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

Smurph · 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.

Jasconius · 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.

Tzyr · 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.

Deebaser · 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.

Deebaser · 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.

^
^
^
^

Ganluan · 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.

BoGs · 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

Ganluan · 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

BoGs · 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.

RiemannLives · 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.

Ganluan · 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.

Penny Arcade

Quick Links

Interview Help, Please :) [Software Design]

Posts