Saturday, December 5, 2015

Conducting Technical Interviews - Part 2

This is a continuation of Conducting Technical Interviews - Part 1. In that, we discussed the traditional way to hire for a technical position.

In this blog, we look at a new way to access technical ability in a world where software controls the lives of millions of people.

1. The Challenge

There are 5 flaws in the traditional technical interview:

1.1. Work experience
The process treats all candidates like interns - ignoring their work history. This is both insulting to the candidate and counter productive.

As an aside, I once suggested to an interviewer that they look at some of my published work. That interviewer was shocked that I would dare suggest suggest such a wasteful activity.

1.2. Overemphasis on basic knowledge
In a typical interview, candidates are asked intern-level questions such as:
1. What is a class?
2. What is polymorphism?

Who cares if the candidate doesn't remember a specific aspect of the language or or a specific command or method? That's what Google/Bing and YouTube is there for, isn't it?

Also, is being able to find a palindrome that important to your business?

1.3. Thought Processes
In a traditional technical interview, the manager gives questions to see a person's thinking process.

The flaw here is, the hiring manager may not have the expertise needed to evaluate a candidate.

Having expertise in a field does not in any way mean you can tell if someone is qualified, especially when dealing with meaningless questions such as, "How do you sort an array of integers?"

1.4. Unnatural Situation.
The interview process is unnatural.

The interviewer is trying to judge whether to hire a candidate. The candidate is trying to make a good impression. Given the constraints of time, etc., can a true judgement of ability be made in such a situation.

1.5. The Interviewer
Be honest hiring manager, do you think you are qualified to judge someone in an hour-long interview? Were you even trained? Also, are personal biases getting in the way of hiring the best of the best?

2. Suggestions

For overcoming the problems of the interview process, I have 2 suggestions.

2.1. Finding Candidates
In my opinion, the best way to find candidates is to visit the various professional groups. There you can see how a person interacts with others , and can examine what they produce.

This includes MeetUp.com groups.

In a previous blog I suggested some professional web sites:
    1. http://stackoverflow.com/
    2. http://www.codeproject.com/
    3. http://www.codeplex.com/
    4. https://github.com/


2.2. Open Source - The Smart Way to Screen
Open source projects are becoming ever more popular. Even Microsoft embraces it. As a hiring manager, you can use this to evaluate the technical abilities of candidates.

How do we do that?

2.2.1. The Basics
By nature, the source code of Open Source projects is freely available to anyone.

For example, anyone can go to GitHub.com and download, fork and modify any project.

Another feature of Open Source projects is that you can submit bug fixes and new features to the owner. The owner then examines the change and decides to ether integrate it with the existing code base or reject it.

2.2.2. Select a Project
To leverage Open Source as an screening tool:

  1. Decide on the technologies you need for your business.
  2. Select a project that uses those technologies.

2.2.3. Issue the challenge
When interviewing a candidate, require them to submit code to an Open Source project of your choosing, or to one that is on your accepted list.

By submitting code, the candidate demonstrates their ability to understand large scale projects and can make meaningful contributions to a greater cause.

Some projects (such as dotnet / coreclr) have extremely high quality bars, since it affects millions of people. This ensures you are dealing with a competent candidate, allowing you to dispense with the technical part of the technical interview.

Happy hunting :-)

Friday, May 8, 2015

Encapsulating property state in C#

Introduction

In computer programming the state of an object is stored in data fields. This allowed callers to view and modify the state of the object at will.

This had two drawbacks:

  1. Since the fields were uncontrolled, we had to validate the data every time we needed to use it. (This wasn’t essential for private fields, but data corruption was possible.)
  2. We cannot know when fields are updated.

To overcome the above problems, people used 'get' and 'set' methods and hide the underlying field. This was cumbersome and unnatural. As a result, C# introduced properties.

C# Properties - syntactic sugar

C# properties encapsulated the state of an object, as seen by external callers. The external caller could now reference the state in a more natural way, while still ensuring a consistent state.

The advantage of properties is that IDEs such as Visual Studio can do reference counting. Also, they are necessary when using the MVVM model with WPF programs.

private string _MyProperty;

public string MyPropery
{
    get
    {
        return _MyProperty;
    }

    set
    {
        // Add validation code here
        _MyProperty = value;
    }
}
Unfortunately, with this we have four problems:

  1. Broken encapsulation. We can easily bypass validation and break encapsulation by using _MyProperty directly within the class.
  2. Infinite recursion. If you're not careful and mix using _MyProperty and MyProperty, you might end up with one calling the other endlessly.
  3. Refactoring. Since we have two items referring to the same logical state, added complexity is introduced when the time to refactor the code comes.
  4. The maintenance costs increase as the number of properties increase. This can be seen in WPF programs that use the MVVM model. It can be a pain maintaining 30 public properties, referencing 30 private fields that do nothing but store state.

Therefore, C# properties don't encapsulate state in any object oriented way.
There is an exception to this.

public string MyProperty { get; set; }

public string MyReadOnlyProperty { get; private set; }

With this construct, the compiler creates a hidden field that holds the state. Unfortunately, this is little more than a field with a few added benefits.

C# Properties - true encapsulation, true OOP

To enable true OOP properties, we need to be able to encapsulate state. I would like to propose two possible ways of encapsulating state.

Dedicated keyword $state

We can introduce a keyword to represent state. The compiler creates a hidden private class-level field to store the state.

Note: This is not a replacement for private fields.

public string MyProperty
{
    get
    {
        return $state;
    }

    set
    {
        if (!$state.Equals(value))
        {
            // Validation code
            // Kickoff relevant events
            // Assign $state as necessary, or throw an exception
        }
    }
}

The keyword $state is only valid within the body of a get or set.

Used within the class, it would look like this:

public class MyClass
{
    public string MyProperty
    {
        get
        {
            return $state;
        }
    
        set
        {
            if (!$state.Equals(value))
            {
                // Validation code
                // Kickoff relevant events
                // Assign $state as necessary, or throw an exception
            }
        }
    }
    
    // Constructor
    public MyClass(string newProperty)
    {
        MyProperty = newProperty;
    }
    
    public string SomeMethod1()
    {
        // Syntax error. $state means nothing within this context.
        return $state;
    }
    
    public string SomeMethod2()
    {
        return MyProperty;
    }
}

Turn a property into a pseudo class
I include this as something for people to think about. What if we treat properties as pseudo classes?

public string MyProperty
{
    String myState;

    // Initialize state of property at object creation time.
    MyProperty(string state)
    {
        myState = state;
    }

    get
    {
        return state;
    }

    set
    {
        if (!state.Equals(value))
        {
            // Validation code
            // Kickoff relevant events
            // Assign $state as necessary, or throw an exception
        }
    }
}

Thursday, February 5, 2015

The Technical Interview

I'm no stranger to the technical interview.

During the last 8+ years, I've gone through the Microsoft Interview Loop dozens of times. That is the price I pay for being a contractor.
The interesting thing about the process is that they always ask the same questions, regardless of what's on your resume.

Recently I got a chance to interview people, and I got a surprise of my life. Most people will fail the interview process because they never prepared. That's so sad, since the Internet is filled with great resources. Additionally, plenty of books have been published on the technical interview.

1. Basics
In a technical interview, the interviewer is looking for two things:
   1: They want to know if you can create effective code.
   2: They are looking to see how well you can think on your feet.

1.2. Efficient code
The first part revolves around data structures and algorithms.

1.2.1 Data Structures
Data structures include:
    - Singly Linked Lists
    - Binary Search Trees
    - Arrays of Integers

Questions include:
    - Sort an array of integers
    - Add/remove an element from/to a BST
    - Find the second to last element of a linked list.
    - Reverse words in a string (Linear time)

More questions can be found in my blog below.
Also, remember to Google for "Technical Interview"

When answering technical questions:
  1. Aim for the most efficient algorithm possible. That is:
    1. Aim to solve problems in linear time - that is, using only one loop.
    2. Use N Log(N) time if absolutely necessary.
    3. Never use N squared time (embedded loops). They will question anything above linear time.
  2. Avoid shortcuts:
    1. Never use built-in functions to do the job. This is a test.
    2. You build your own nodes and classes for the linked list and BST problems.
  3. Always explain what you are doing.
    1. Tell why you used one algorithm over another.
    2. Offer suggestions on how to best leverage existing frameworks.
1.2.2. Algorithms
Algorithms include:
    - Fibonacci sequence
    - Get Nth Factorial
    - Prime numbers
    - Use recursion
    - Don't use recursion

As with algorithms, you need to explain your reasoning. Also remember, linear time is always the best.

1.1. Thinking on your feet
They will ask probing questions to see your thought processes.

This is also the place where they will ask test related questions. You need to test your code by giving various inputs. Again, this is a skill that must be mastered.

2. Show and Tell
Keep in mind, interviewers expect people to lie and spout stuff.

As an example, I interviewed a person who loved saying, 'I create effective test cases'. I asked him to test a hat. (My hat was a standard baseball hat with a logo.) He couldn't think of basics such as durability, attractiveness, marketability, maintainability (easy to clean, etc.), production (material costs, labor costs, manufacturing related laws, etc.), disposal (environmental impact of its disposal, etc.), etc.

I also met people who claimed to know how to program. When questioned, they admitted they didn't know how to program.

Interviewers don't care about the past. You helped create the Internet? That was years ago, and that technology is now obsolete. Are you obsolete?

Remember: Your resume only serves to get you to the interview. After that it is useless.

So what should you do?

2.1. Show and Tell
I interviewed a man with acceptable skills. I then asked him if he published anything. He then showed me a 3-D game on his phone where you rotate objects on the screen. That proved to me he had mastered the data structures and algorithms skills the company was looking for.

If you have published something cool, show it.

2.2. Reputation
Smart recruiters will not bother with resumes. Instead they will troll professional web sites for candidates.

These sites include, but not limited to:
    1. http://stackoverflow.com/
    2. http://www.codeproject.com/
    3. http://www.codeplex.com/
    4. https://github.com/

Also remember to blog.

By publishing to these places, people can see what you are capable of and have confidence in hiring you.

3. Conclusion
  1. Your resume serves only one purpose. That is to get an interview. After that, it is useless.
  2. Regardless of your experience, if you can't answer the above questions, you will fail the technical interview.
  3. Mastering the technical interview is an essential skill. Master it and you will land your next gig.
  4. Remember - your search engine is your friend.
Finally: Share your knowledge and experience, and your reputation will skyrocket. In the world we live in, this is the best way to secure your future and earn what you are entitled to.

4. Resources

My Blogs:
Some Books:
Some sites: