Technical Interview Questions and Answers

I recently read Scott Hanselman’s post on technical interviews.

I took a stab at answering those for my own amusement.  I took a bit of time to research the questions to ensure my answers are correct (as far as I know anyway).  So, I thought, why not post them and get some feedback?  Also, I often times put articles on my blog to help me have one site I can use as a quick reference for issues I encountered in my career..

  • What is Software Craftsmanship movement??

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

· Not only working software, but also well-crafted software

· Not only responding to change, but also steadily adding value

· Not only individuals and interactions, but also a community of professionals

· Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

  • What are principles of OOP?
    • In traditional computer science courses those are encapsulation, inheritance and polymorphism.
      • Encapsulation
        • Restrict access to some implementation details, only expose public (consumable) methods. Ability to bundle methods and data into constructs (classes).
      • Inheritance
        • Reuse attributes and behavior of objects by basing classes on other classes.
      • Polymorphism
        • An ability to create function, object or variable that has more than one form / implementation. As a result different objects can respond to the same message in different way.
  • What is SOLID?
    • Single Responsibility Principle
      • The notion that an object should have only a single responsibility. As a result, an object will have a single reason to change, minimizing the maintenance efforts and limiting the impact of a change
    • Open/Close Principle
      • The notion that software entities should be open for extension, but closed for modification. The idea was that once completed, the implementation of a class could only be modified to correct errors; new or changed features would require that a different class be created. That class could reuse coding from the original class through inheritance. The derived subclass might or might not have the same interface as the original class.
    • Liskov Substitution Principle
      • The notion that objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. If in a computer program if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substitutes for objects of type T), without altering any of the desirable properties of that program
    • Interface Segregation Principle
      • The notion that many client specific interfaces are better than one general purpose interface. The idea is that once an interface becomes too large, it needs to be broken down into a group of smaller interfaces. The idea is that a client of an interface does not need to be exposed to methods that do not pertain to that client.
    • Dependency Inversion Principle
      • The notion that one should depend upon abstractions instead or concretions.
        • High-level modules should not depend on low-level modules. Both should depend on abstractions.
        • Abstractions should not depend upon details. Details should depend upon abstractions.
  • Why is the Single Responsibility Principle important?
    • If an object has a single reason to exists, it will only have a single reason to change. Change can be defined as the maintenance of the software, that takes much longer timeframe than the time to initially create the software. If we minimize the reason for change, we will minimize the maintenance costs as well as impacts of that change.
  • What is Inversion of Control? How does that relate to dependency injection?
    • In computer programming, Inversion of control (IoC) is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to procedural programming. In traditional programming the flow of the business logic is controlled by a central piece of code, which calls reusable subroutines that perform specific functions. Using Inversion of Control this "central control" design principle is abandoned. The caller’s code deals with the program’s execution order, but the business knowledge is encapsulated by the called subroutines.
    • In practice, Inversion of Control is a style of software construction where reusable generic code controls the execution of problem-specific code. With this approach implementation is decoupled from execution. Ideally, each component of a system would depend on an interface that is implemented by another component. This promoted decoupling, single responsibility principle, and side effects of a change to a component.
    • Dependency injection is a technique that would allow a developer to indicate to a component what other components it can use. In this case we supply a dependency or a reference to a software component. Instead of hard-coding dependencies, a component supplies a list of dependencies it needs to a service/DI framework.
  • How does a 3 tier application differ from a 2 tier one?
    • Tiers refer to physical computer boundaries. Two tier applications will have a UI tier (client tier) and database tier. Three tier applications will typically have UI/client tier, application server (services) tier and database tier.
  • Why are interfaces important?
    • They minimize dependencies between objects by hiding implementation details that a component exposes from a consumer of that component. It allows for substitution of one component with another, without consumer changing any code. It serves directly to polymorphism principle of OOP.
  • What is the Repository pattern? The Factory Pattern? Why are patterns important?
    • Repository pattern typically refers to as dependency free access to data. In this case consumer of data only takes dependency on interfaces or POCO objects. It is important because it minimizes coupling and directly serves Dependency inversion principle.
    • Factory pattern refers to object creation without specifying exact class to be created. Typically they return interfaces.
  • What are some examples of anti-patterns?
    • Premature optimization
    • Code features you do not currently need
    • Copy/paste inheritance
  • Who are the Gang of Four? Why should you care?
    • The authors of the Design Patterns Book came to be known as the "Gang of Four." The name of the book is "Design Patterns: Elements of Reusable Object-Oriented Software", came to be known "book by the gang of four". After all, it isn’t the ONLY book on patterns. That got shortened to "GOF book", which is pretty cryptic the first time you hear it.
      • Erich Gamma
      • Richard Helm
      • Ralph Johnson
      • John Vlissides
    • Design patterns can speed up the development process by providing tested, proven development paradigms.

Please leave comments as you see fit.  I hope this will start a mutually beneficial conversion.

2 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *