Ask Questions That Really Matter: It’s a matter of trust
A company that can be trusted will clearly define its core values and live by them. To be truly meaningful, these values will be part of the company’s culture instead of merely listed on its Web site. During the interview, ask questions such as:
• What are the core values of this company?
• Can you give me a personal example of how these values guide your decisions?
• Do you believe the company’s actions are consistent with these values?
• Would the people who work for you say that you could be trusted?
The answers you hear should include real examples of how values guide the day-to-day actions of the interviewer and her team. Programs that recognize employees who exemplify the values will also show you what behavior the company rewards.
Public positions, such as printing the values on business cards, also illustrate this emphasis. Companies that regularly measure alignment with their values through anonymous surveys have the most powerful method for ensuring real consistency between words and actions. Look for not only the measurements, but also how publicly the results are shared.
is vs as in C#
This code
bool b = x is Foo;
could be considered as a syntactic sugar for
bool b = (x as Foo) != null;
in which case is is a syntactic sugar for as. Similarly,
Foo f = x as Foo;
could be considered to be a syntactic sugar for
var temp = x;
Foo f = (temp is Foo) ? (Foo)temp : (Foo)null;
in which case as is a syntactic sugar for is. Clearly we cannot have both of these be sugars because then we have an infinite regress!
The specification is clear on this point; as (in the non-dynamic case) is defined as a syntactic sugar for is.
However, in practice the CLR provides us instruction isinst, which ironically acts like as. Therefore we have an instruction which implements the semantics of as pretty well, from which we can build an implementation of is. In short, de jure is is is, and as is as is is, but de facto is is as and as is isinst.
COM Interop in c# 4.0
// Code simplified for this example
using Microsoft.Office.Interop;
using Microsoft.Office.Interop.Word;
object foo = "MyFile.txt";
object bar = Missing.Value;
object optional = Missing.Value;
Document doc = (Document)Application.GetDocument(ref foo, ref bar, ref optional);
doc.CheckSpelling(ref optional, ref optional, ref optional, ref optional);
There are (at least) three problems with the code above. First, you have to declare all your variables as objects and pass them with the ref keyword. Second, you can't omit parameters and must also pass the Missing.Value even if you are not using the parameter. And third, behind the scenes, you are using huge (in file size) interop assemblies just to make one method call.
C# 4.0 will allow you to write the code above in a much simpler form that ends up looking almost exactly like 'normal' C# code. This is accomplished by using some of the features already discussed; namely dynamic support and optional parameters.
// Again, simplified for example.
using Microsoft.Office.Interop.Word;
var doc = Application.GetDocument("MyFile.txt");
doc.CheckSpelling();
Named Parameters in C#4.0
In the last example, we saw that the following call was invalid:
Process( "foo", myArrayList ); // Invalid!
But if the boolean ignoreWS is optional, why can't we just omit it? Well, one reason is for readability and maintainability, but primarily because it can become impossible to know what parameter you are specifying. If you had two parameters of the same type, or if one of the parameters was "object" or some other base class or interface, the compiler would not know which parameter you are sending. Imagine a method with ten optional parameters and you give it a single ArrayList. Since an ArrayList is also an object, an IList, and an IEnumerable, it is impossible to determine how to use it. Yes, the compiler could just pick the first valid option for each parameter (or a more complex system could be used), but this would become impossible for people to maintain and would cause countless programming mistakes.
Named parameters provide the solution:
ArrayList myArrayList = new ArrayList();
Process( "foo", true ); // valid, moreData omitted
Process( "foo", true, myArrayList ); // valid
Process( "foo", moreData: myArrayList); // valid, ignoreWS omitted
Process( "foo", moreData: myArrayList, ignoreWS: false ); // valid, but silly
As long as a parameter has a default value, it can be omitted, and you can just supply the parameters you want via their name. Note in the second line above, the 'true' value for ignoreWS did not have to be named since it is the next logical parameter.
Optional Parameters in C#4.0
Support for optional parameters allows you to give a method parameter a default value so that you do not have to specify it every time you call the method. This comes in handy when you have overloaded methods that are chained together.
The Old Way
public void Process( string data )
{
Process( data, false );
}
public void Process( string data, bool ignoreWS )
{
Process( data, ignoreWS, null );
}
public void Process( string data, bool ignoreWS, ArrayList moreData )
{
// Actual work done here
}
The reason for overloading Process in this way is to avoid always having to include "false, null" in the third method call. Suppose 99% of the time there will not be 'moreData' provided. It seems ridiculous to type and pass null so many times.
// These 3 calls are equivalent
Process( "foo", false, null );
Process( "foo", false );
Process( "foo" );
The New Way
public void Process( string data, bool ignoreWS = false, ArrayList moreData = null )
{
// Actual work done here
}
// Note: data must always be provided because it does not have a default value
Ask Questions That Really Matter: Rely on your involvement and your contribution.
Companies that want employees to be fully committed will encourage high participation and open discussion in how goals are set and decisions are made. Ask questions such as:
• Can you tell me the company’s three most important goals for this year?
• How involved will I be in setting my personal goals and the goals for my team?
• Can you give me a recent example of a decision where I would have been consulted?
• Do the people who work for you ever tell you that you’re wrong?
Look for methods and a mindset that encourage employees to offer feedback on decisions, even high-level ones. Once the overall goals are set, great companies allow teams to establish their own goals -- so long as they are in alignment. This is because they know that the greater the employee involvement, the greater their commitment will be.
Define LeaseTime, SponsorshipTime, RenewOnCallTime, LeaseManagePollTime in .NET
Terms related to lifecycle of a remoting object.
The LeaseTime property protects the object so that the garbage collector does not destroy it as remoting objects are beyond the scope of the garbage collector. Every object created has a default leasetime for which it will be activated. Once the leasetime expires, the object is eligible again for garbage collector and is eventually destroyed. Default value is 5 minutes.
Even though the leasetime of an object has expired, there still may be clients who would still need the remoting object on the server. In such cases the leasemanager keeps a track of such clients and asks them if they need the object and are ready to extend or sponsor the object to extend its existence. This is done through SponsorshipTime property, which is then based on the sponsor.
The RenewOnCallTime property defines the duration for which a remoting object's lease is extended if a sponsor is found. The default value is 2 minutes.
The LeaseManager class has a property PollTime, which defines the frequency at which the LeaseManager polls the leases. Default is 10 seconds.
