The marker interface is an interface that is empty. It does not implement any properties nor methods. It is used to mark the capability of a class as implementing a specific interface at run-time. In languages that do not provide support for associating metadata to a class, this approach can be useful. In C#, metadata attributes are available to apply to a class, and according to the .NET Framework 3.5 Design Guidelines for Developing Class Libraries, marker interfaces should be avoided.

When I first noticed these marker interfaces in project I immediately thought it was a code smell. It just did not seem "right." Why provide an interface that defines nothing? Why provide a marker interface that implements a non-marker interface? Obviously there must be a reason for this?

Two sources encourage me to avoid using marker interfaces and to use attributes in C#. Interface Design and .NET Type Design Guidelines - Interface Design.

There advice is to avoid this...

public interface IFooAssignable {}

public class FooAssignableAttribute : IFooAssignable

{

    // ...

}

And to embrace this approach...

[FooAssignable]

public class Foo

{

    // ...

}

public class FooAssignableAttribute : Attribute

{

    // ...

}

There appears to be more work involved in writing "good" code.

If I am using "marker" interfaces, I can do this...

if(foo is IFooAssignable)

{

    // ...

}

If I am using attributes, I can do something like this...

object[] attributes = foo.GetType().GetCustomAttributes(false);

foreach (string attribute in attributes)

{

    if(attribute == "FooAssignable")

    {

        // ...

    }

}

Or, thanks to Jarod Ferguson's suggestions on using extension methods and LINQ, I could have this...

public static class AttributeExtensions

{

    public static bool IsAttributedAs<T>(this object obj)

    {

        if(obj.GetType().GetCustomAttributes(false).Where(x => x is T).ToList().Count == 1)

            return true;

        return false;

    }

}

// Then wherever I want to check for the attribute marker...

if (foo.IsAttributedAs<FooAssignableAttribute>())

{

    // ...

}

At this point, while "marker" interfaces are a code smell to me, I am still on the fence when it comes to using them versus custom attributes. I will more than likely tend to favor the attribute approach, unless I can prove that the cost of reflection is too expensive for my situation. I admit, I will do what I can to omit marker interfaces, perhaps by using some other interface where possible.

What are you doing in situations like this? Can you offer me a more elegant solution?

For software engineers, the job interview process typically starts with a technical, phone screen where a candidate's skills are verified against their resume. The end goal is to determine, "are they who they say they are on their resume?" and "can they meet or exceed our expectations for this position?" The phone screen is far from perfect. Good candidates can be overlooked and bad candidates can proceed further. The nature of the screen is prone to error. If we devise a plan and execute it, we improve our chances of finding the right candidates and saving ourselves time and money.

After the technical screen, a coding assignment may initiate the next stage of the interview process, followed by an in-person interview. If all goes well, contract negotiations complete the process. Organizations can budget a decent amount of money for each candidate, so it is important to approach each stage of the interview process with a plan. A bug becomes more expensive to fix the further into the product lifecycle it survives. Like a bug discovered after the product ships, a candidate discovered to be dud during the full day interview becomes a financial loss. The phone screen now becomes a more integral part of the interview process. We have a short amount of time to uncover a potential fit with a candidate we have yet to meet. 

Internally, interviewing is about finding the best candidate who currently meets, exceeds, or potentially can meet the desired skill set, shows passion and motivation, and fits with the organization's culture. Externally, interviewing is about public relations and perception. At each stage in the interview process we want our candidates to be challenged and think positively about both the interview process and the organization.

The impression the candidate takes out into the market is important if we care about our image. Our goal is to conduct a professional interview such that, regardless of the outcome (hire/no hire), the candidate's impression of the company is high. Word travels fast and negative rapport hurts recruiting. We tend to remember the negative experiences more vividly then the positive, so treat the candidates professionally and respectfully, and by all means, conduct the interviews with staff trained to interview and mature enough to represent the company. On several occasions I have witnessed interviewers conducting themselves as if they are being interviewed by their peers and managers in the room.

The goal of the phone screen is to assess the candidate's skills to determine if he/she would be technical enough to be successful during a full day interview. We want the candidate to walk away from the interview feeling rewarded and good about themselves and the company. We want to determine fit as soon as possible to save us time and money and have the candidate save face.

The Plan

The phone interview should be "in and out," just like a robbery. Have a plan of attack. Whether it is interviewing or playing a football game, those who are successful execute a plan. In college we followed a plan for every game. "Convert third downs. Don't give up the big play. No turnovers. No penalties. Execute the kicking game. Execute special teams. Don't flinch." I am sorry I cannot recall all of them. When we followed the plan we found success. When we were not successful, we could easily identify which part of the plan we did not execute. Interviewing can use the same approach.

Have a plan or a script in front of you during the interview. Settle on some questions you feel will help determine technical skills and stick to them. Have some backup questions. If the candidate answers this way, delve into his response with this. If he fails to answer, ask him this, or move on, ect. Assuming your plan works and you continually hone it, execute the same plan for each candidate. Make your interviewers understand the plan. Have them execute it. Have them believe in it.

My Typical Plan

• Schedule 30 minutes with the candidate over the telephone in a quiet room away from distractions
• Send the candidate a live meeting request
• Be prompt, be prepared
• Determine fit as soon as possible
• Drive the discussion
• Small introduction
• Warm up questions
• Get them writing code
• Assess how they have done at this point
• Good - continue further questioning and begin selling us more
• Bad - conclude. Remember, the longer we stay on, the more attached we become.
• Conclude
• Follow up with the recruiter

For me, the two most important concepts to take away from the phone screen are drive the discussion and get them to write code. Driving the discussion keeps the interviewer in charge of the interview and enables proper execution of the plan. The longer we stay on the phone, the more susceptible we are to making decisions based on emotion rather than fact. Drive the discussion and stay in command.

Get the candidate to write code. Do not assume because they can talk about a technology that they are comfortable working in it. Use live meeting and a have them write a function, refactor a class, provide a working example of polymorphism. Better to find out now if they cannot write code than further into the interview process.

The technical screen is more important than we tend to believe. Devise a plan and execute it. Lead the interview and determine as soon as possible if this candidate possess enough skills and experience to be successful within your organization. Be professional and respectful. We want the candidate to think positively about the company regardless of the outcome.