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 groups.

In a previous blog I suggested some professional web sites:

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 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#


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
        return _MyProperty;

        // 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
        return $state;

        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
            return $state;
            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;

        return state;

        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:

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:

Saturday, September 6, 2014

What is Agile?

What is Agile?
  • Agile development is what we use to develop software.
  • Waterfall is what competitors use to develop software.
Simple question - simple answer.

Countless development processes have been developed to speed up the development of software.
Examples being: kanban, scrum, xp, lean, SAFe, CMMi, and ScrumXP to name a few

Factoid: Even though discredited, Waterfall was developed to speed up development and improve quality.

1. Question: So what is agile?

Answer: Agile is any process that parallelizes development.


Let's say you are shipping product X. Your customers give you a list of requirements. One month later they ask why it's taking so long.

1.1. Waterfall Answer:
I'm sorry but first we need to understand the requirements, then build infrastructure, then create the product and then test.

1.2. Standard Agile Answer:
We have broken up your requirements into multiple parts and each team is working in parallel. However, they number of requests you submitted is too much for our team to handle. We either need more time or more resources.

1.3. Super Agile Answer:
Here is what we did. Here is our backlog. If you wish, here are the APIs that we currently use. Please be free to extend the product if you are able and willing to do so.

2. Question: So what is Agile?
Answer: It is a process where you parallelize the work and let many people work on the project at the same time. The more you can separate the tasks into multiple parallel tasks, the more agile you are.

2.1. Open Source Projects:
In my opinion open source projects hosted in repositories such as GitHub are the ultimate in agile, since anyone can fork the work and drive the project in ways no-one who started the project could foresee.

Agile is an evolutionary process that drives the development of a project. Each new contributor is free to add and change things. At the end of the day the best solution wins and is integrated into the main product.

2.2. Never say "By Design"
The key to Agile is the integration of diverse views into a product designed to satisfy the needs of the Customer.

Many developers defend the current state of a product by saying that the feature is by design. That is anti-Agile thinking. Any feature that fails to meet the needs of a customer needs to be removed or redesigned. Any feature that goes against the expectations of a customer Must be removed or redesigned.

It is true that some processes need to work in a certain way for logical reasons. This must be clearly documented and processes that satisfy the customer must be explained. However, just because something has been done one way is no reason why we should continue doing it that way.

Example: Microsoft Excel has a global undo stack. It was created that way from the beginning. However it breaks the encapsulation principle where work on one object shouldn't affect work on another project. Also, it is standard for all document editors to maintain a separate undo stacks for each document. That way, changing one document won't have unexpected effects on another document.

If you ask the Excel developers, they would say that it is by design - however that is a design that can't easily be defended, especially since I have lost work because of that so-called design.

3. Finally

Question:So what is Agile?
Answer: Agile is any process that exceeds (or at least satisfies) the customer's expectation, allowing for a greater revenue stream.

Wednesday, July 16, 2014

The Flaws in Microsoft’s Windows Store (Windows 8, 8.1)

There is no question that Microsoft’s Windows Store is convenient.
  1. It allows people to download applications in a seamless way.
  2. It allows easy upgrades of applications.
  3. It’s an incredible platform that allows anyone to develop and sell applications that can compete with the big players.
  4. It is more secure than regular desktop apps since Microsoft verifies applications before posting.
However, Windows Apps have a few major issues that Microsoft needs to address.

1: Performance

Microsoft’s Windows Store Apps have horrible startup performance.
Try this performance test on Windows:
  • Open Visual Studio and create a new Windows Store Application
  • Run the application without changes
The splash screen appears.
After a few seconds, the main app starts.
  • Switch to either the desktop or another Windows Store app
  • Switch back
The splash screen appears again and stays there for at least a second.

Why does it take so long for the application to start, even though there is no user code?

The answer is that Windows stops the application and saves its state. It then reloads the app when the user switches back.

2: Attention Hog

Imagine you execute a command that takes ten seconds to complete. If you were running a traditional desktop application, you could switch to another program and then switch back when the application completes its task.
Unfortunately that is not an option with Windows Store Apps. Windows pauses the application the moment you switch away from the app.
It is true that applications can do some background work while paused. However, in my opinion, this will make the application unnecessarily complicated.
Also, Windows only gives the application 2 seconds of processor time for every fifteen minutes of run time*. That means the application might take hours to execute a command that would otherwise take seconds.
Currently the only thing the user can do is sit at the computer and do absolutely NOTHING while the application does what it needs to do.
Many applications work best when run in the background. A perfect example is your music application. It plays music in the background while you do other things. A Windows Store App is currently not an option since switching away would shut off the music.
I like listening to WARM 106.9 in my web browser. (URL: How would I listen to that if the web browser were not in the front and taking up monitor real estate?

The same is true for video processing applications that perform time-consuming tasks.
> Windows Store applications force users to give applications 100% of their attention and prevent them from multi-tasking.
What can be done?
The solution is to allow the user to decide if an application should be paused when switching away from it.
Ideally the user should have two choices:
  1. Users need a global switch to turn on or off whether all Windows Store apps are paused
  2. Users need to be allowed to create exceptions. Ideally users should be able to do this through the task manager.
Since the ability to pause an app affects power consumption, it would make sense that it be in ‘Control Panel\Hardware and Sound\Power Options’.
The user would then choose application sleep options based on if the computer is plugged in or if it is running on batteries.

By letting application run in the background like regular desktop applications, the time delay for switching applications should be eliminated. This would give users a better user experience.

3: Windows Store Crashes

I notice that Windows Store applications can be very temperamental. For example I sometimes like playing Microsoft Solitaire or Mahjong. However, it tends to crash a lot when I do the daily challenges. This tells me two things:
  1. Microsoft’s Windows Store is running on Windows Azure and it is close to its limits.
  2. Windows Store applications can’t handle when connectivity is an issue.

4: Conclusion

Windows Store applications could be incredible if Microsoft fixed the performance issue. They also can’t be run as desktop applications. This means some applications, such as a music player, can’t be packaged as a Windows Store application.
My desktop computer is not a phone. Why should I be limited to what a phone can do?
* Professional Windows 8 Programming, Application Development with C# and XAML, 2012, ISBN: 978-1-1182-0570-9, page 168

Object Oriented Programming (OOP) Tutorial

In this blog I would like to present a simple tutorial on the basic principles of Object Oriented Programming (OOP) and the design patterns that are the basis of modern programming.
For convenience I will be using C#.

1. History

The principles of object oriented programming existed even before modern computers came into being. However the so-called 

1. Basic OOP Concepts

Object Oriented Programming is built on three principles: Encapsulation, Inheritance, and Polymorphism.

1.1. Encapsulation

Encapsulation allows you to hide data and implementation details and expose them in a controlled manner through publicly exposed methods.
Objects are self-describing things with internal structure not visible to the external world. They encompass one single idea or concept and they provide methods that allow external objects to interact with them.

1.2 Inheritance

Inheritance allows you to create a new class, using the previously defined methods of a base class.
Your new class will expose the existing methods of the base class as if they were newly defined. As such, creating a method with the same signature as the base class will hide the method in the base class.
NOTE: Inheritance is not polymorphism.

1.3. Polymorphism

Polymorphism occurs when an instance of a child class is treated as an instance of a parent class. Calling a method on the parent class will then express different behaviors, based on how the child class has overridden the parent class method.


As an example, you have a class called ‘Printer’. It defines certain actions, such as ‘Print’.
You then create a child class called Cannon 233. In this class you override the Print method.
You then call the ‘Print’ method on Printer. Since Printer is an instance of Cannon 233, the document is printed using the implementation encapsulated by Cannon233’s overridden method.
NOTE: In C#, polymorphism doesn’t occur unless you use either the key words virtual or abstract.

1. 4. OOP-Class

A class is the basic construct in Object Oriented Programming. As such it supports Encapsulation, Inheritance, and Polymorphism.
Note: When people talk about classes, they are referring to pure abstract classes that don’t have any implementation details. All you have are method signatures. As such, multiple inheritance is allowed.
For example:
pubic class Printer
    int PrintDocument(Document doc);
    Preferences GetPreferences();
    void Cancel(int cancelToken);

An important thing to keep in mind is that it is not the intent of OOP to prevent code duplication. That is just a side-effect of proper OOP design.
1.4.1. Responsibilities
  • Data Consistency: A class is responsible for making sure that the data it encapsulates is in a legal state between method calls.
  • Data Hiding: Class fields (integers, strings, etc.) should always be private. This data should only be exposed through methods.
  • Data initialization: It is the responsibility of the class to begin its life in a consistent state that is useful to the user.
  • Resource Management: Classes must make sure all resources are returned to the system when a task completes.
1.4.2. Data Structures
There is a fundamental difference between a class as defined in OOP and one as defined in a modern language such as C#. Unfortunately they both use the same name, which causes untold confusion. As such I will use OOP-Class to refer to the idea that OOP tries to encapsulate.
The following are various data structures relevant to modern programming…
C# Class
Supports: Encapsulation, Inheritance, Polymorphism
The C# class is the what people think of when they say ‘class’. C# classes are OOP-Class, since they enable encapsulation, inheritance, and polymorphism.
The fact that C# classes are reference types and reside on the heap is not relevant to the concept of an OOP-Class. That’s just an implementation detail.
Supports: Encapsulation, Inheritance, Polymorphism
The C# interface is the closest thing we have to the classic OOP-Class. The reason is that it only defines the operations in terms of method signatures. As a result, multiple inheritance is possible.
Interfaces are important since they are the basis for many design patterns.
Supports: Encapsulation
In C#, a struct is Not an OOP-Class. The reason is because it doesn’t provide inheritance (and polymorphism).
Structs are data structures that are used to implement integers, floats and other value types, including composite values.
Structs implement encapsulation. As a result, methods are exposed to modify its internal state.
C# Enums
Supports: <None>
In C#, an enum is Not an OOP-Class. The reason is because C# enums are just named lists of built-in numeric types such as int and float.
Java Enums
Supports: Encapsulation
In Java, the enum is a type of struct that has methods and internal states. However, just like enums, they don’t offer inheritance.
Prototype Collection
Supports: Encapsulation, Inheritance
1.4.3. Objects
Classes define functionality. However, you can’t do anything unless you define an object and assign it states that are useful to the problem at hand.
An object is a data structure containing internal data that is in some valid state.
C# Objects
Objects are self-describing things with internal structure not visible to the external world. They encompass one single idea or concept and they provide methods that allow external objects to interact with them.

1.5. Methods

In OOP, methods encapsulate the specific single action you take to transform your data from its initial state to its final state.
The purpose of methods is to encapsulate actions performed of input data. When creating methods, you must ask yourself – What are the logical operations you are exposing through your API?
1.5.1 Method Variations
In traditional OOP, there is classes only implement methods. However, modern languages have variations on the theme. This allows us to encapsulate different design patterns within the language.

In C#, properties allow you to encapsulate internal fields and expose them to the caller. This allows the class to enforce policies that ensure its internal state is always consistent between method calls.
Static Methods
Static fields and methods are an odd thing in OOP. They don’t exist in traditional OOP.

1.6. Conclusion

A programming language is considered object oriented if it implements a class as defined above.
According to the above definition C++ is an object oriented programming language.
That’s so last century. Smile with tongue out
When I think of OOP, I think of languages such as Java and C#, where everything is an object. It is impossible to program without creating a class definition and then calling methods on the class.
With C++, object oriented programming is possible, but not required.

2. Design Patterns

Design patterns are a funny thing. Everyone who has programmed with modern languages use the patterns without knowing that they are doing so. The reason is that many of them are built into the language.

3.1.1 Struct

A struct is a special type of class that is used to define values or collections of values.
The fundamental difference between a value type object


Friday, May 2, 2014

Prototype Collection

Objects in Object Oriented Programming can have arbitrary values. For instance, a string can contain any number of characters and a character can have any value.

However, not all values are relevant with regards to the problem space.


From Java, a classic example is the Planet class.

Planet data includes:

  • Average distance from the sun
  • Diameter at equator
  • Axis tilt
  • Rotation direction
  • Length of day
  • Length of year
  • Number of satellites
  • Type (Rocky, gaseous, etc.)

Obviously fields can have any value. There are an infinite possibility when it comes to planets. However, we only have 8 formally recognized planets in our solar system (the rest are planetoids, asteroids, etc.)

When we create an object of type Planet, we specify values for each property of the planet object. For instance, for Earth, we define LengthOfDay to be 86,400 seconds.

This is where prototypes come in.


A prototype is an object containing predefined values that has special significance to us.

This prototype is then copied and used wherever it is needed.

Using the Planet example, we can define prototypes for all the official solar system planets - Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, and Neptune.

(Pluto is in another list called Planetoids, which possibly inherits from Planet)

The concept of the prototype was so significant that the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) included it in their book, Design Patterns: Elements of Reusable Object-Oriented Software (Copyright 1995).


Serialization is a process of storing the state of an object in a portable format, such as a text string or XML document. This allows us to create a duplicate object at a later time.

Using serialization we can store object states that have significance for later use.

Prototype Collection

Since we have any number of prototypes for a specific object, we can collect these prototypes into a collection.

In java, this concept is encapsulated in its enumeration structure:






C# -
  1. public class Planet
  2. {
  3.     public static readonly Planet Mercury = new Planet("Mercury", 3.303e+23, 2.4397e6);
  4.     public static readonly Planet Venus = new Planet("Venus", 4.869e+24, 6.0518e6);
  5.     public static readonly Planet Earth = new Planet("Earth", 5.976e+24, 6.37814e6);
  6.     public static readonly Planet Mars = new Planet("Mars", 6.421e+23, 3.3972e6);
  7.     public static readonly Planet Jupiter = new Planet("Jupiter", 1.9e+27, 7.1492e7);
  8.     public static readonly Planet Saturn = new Planet("Saturn", 5.688e+26, 6.0268e7);
  9.     public static readonly Planet Uranus = new Planet("Uranus", 8.686e+25, 2.5559e7);
  10.     public static readonly Planet Neptune = new Planet("Neptune", 1.024e+26, 2.4746e7);
  11.     public static readonly Planet Pluto = new Planet("Pluto", 1.27e+22, 1.137e6);
  13.     private Planet(string name, double mass, double radius)
  14.     {
  15. = name;
  16.         this.mass = mass;
  17.         this.radius = radius;
  18.     }
  20.     public static IEnumerable<Planet> Values
  21.     {
  22.         get
  23.         {
  24.             yield return Mercury;
  25.             yield return Venus;
  26.             yield return Earth;
  27.             yield return Mars;
  28.             yield return Jupiter;
  29.             yield return Saturn;
  30.             yield return Uranus;
  31.             yield return Neptune;
  32.             yield return Pluto;
  33.         }
  34.     }
  36.     public string Name { get { return name; } }
  37.     private readonly string name;
  39.     public double Mass { get { return mass; } }
  40.     private readonly double mass;   // in kilograms
  42.     public double Radius { get { return radius; } }
  43.     private readonly double radius; // in meters
  44. }






Please keep in mind that a prototype collection has no functionality. The only thing it can do is return a specified prototype and allows you to verify if two prototypes are equivalent.

As a result, many use the Java enumeration type incorrectly, by adding functionality.


































IceRocket Tags: ,