Click here to Skip to main content
Click here to Skip to main content

Facing .NET Technical Interviews: Part 1

, 26 Dec 2005
Rate this:
Please Sign up or sign in to vote.
A brief preparation on technical stuff for interviews on .NET.


Seems that I am going to provide instructions regarding how to face technical interviews on .NET. I am sorry but this is not the content of this article series. I have worked a lot on preparing technical questions asked during interviews for various development positions.

In this series of articles I am going to explain some of questions asked frequently during technical interviews, in the beginning (In this and subsequent article) we will go through core technical stuff and after that I will explain some of the tricky and confusing concepts.

During technical interview on .NET generally questions are asked on .NET Framework, VB.NET, C#.NET, Managed C++, ASP.NET etc. Questions can be conceptual as well as related to practical problems also, in this series I will cover conceptul questions first and then some questions on practical problems.

Instead of talking much on introduction let's start the business.

Microsoft .NET

.NET Framework:
.NET framework is an environment that facilitates Object Oriented Programming Model for multiple languages. It wraps Operating System and insulates Software Development from many Operating System specific tasks such as file handling, memory allocation & management.
It has two main components CLR (Common Language Runtime) and .Net BCL (Base Class Libraries).
Sample screenshot
As you can see in Figure, the .NET Framework sits on top of the operating system, which can be a few different flavors of Windows and consists of a number of components. .NET is essentially a system application that runs on Windows.

The most important component of the Framework is something called the CLR. If you are a Java programmer, think of the CLR as the .NET equivalent of the Java Virtual Machine (JVM). If you don't know Java, think of the CLR as the heart and soul of the .NET architecture. At a high level, the CLR activates objects, performs security checks on them, lays them out in memory, executes them, and garbage-collects them. Conceptually, the CLR and the JVM are similar in that they are both runtime infrastructures that abstract the underlying platform differences. However, while the JVM currently supports just the Java language, the CLR supports all languages that can be represented in the Common Intermediate Language (CIL). The JVM executes bytecode, so it could technically support many different languages, too. Unlike Java's bytecode, though, IL is never interpreted. Another conceptual difference between the two infrastructures is that Java code runs on multiple platforms with a JVM, whereas .NET code runs only on the Windows platforms with the CLR (at the time of this writing). Microsoft has submitted the Common Language Infrastructure (CLI), which is functional a subset of the CLR, to ECMA, so a third-party vendor could theoretically implement a CLR for a platform other than Windows.

An assembly is the basic unit of deployment and versioning, consisting of a manifest, a set of one or more modules, and an optional set of resources.

.NET Portable Executable File:
A Windows executable, EXE or DLL, must conform to a file format called the PE file format, which is a derivative of the Microsoft Common Object File Format (COFF). Both of these formats are fully specified and publicly available. The Windows OS knows how to load and execute DLLs and EXEs because it understands the format of a PE file. Given this, any compiler that wants to generate Windows executables must obey the PE/COFF specification.

Standard Windows PE files are divided into two major sections. The first section includes the PE/COFF headers that reference the contents within the PE file. In addition to the header section, the PE file holds a number of native image sections, including the .data, .rdata, .rsrc , and .text sections. These are the standard sections of a typical Windows executable, but Microsoft's C/C++ compiler allows you to add your own custom sections into the PE file using a compiler pragma statement. For example, you can create your own data section to hold encrypted data that only you can read. Taking advantage of this ability, Microsoft has added a few new sections to the normal PE file specifically to support the CLR's functionality. The CLR understands and manages the new sections. For example, the CLR will read these sections and determine how to load classes and execute your code at runtime.

The sections that Microsoft has added to the normal PE format are the CLR header and the CLR data sections. While the CLR header stores information to indicate that the PE file is a .NET executable, the CLR data section contains metadata and IL code, both of which determine how the program will be executed.


Metadata is machine -readable information about a resource, or "data about data." Such information might include details on content, format, size, or other characteristics of a data source. In .NET, metadata includes type definitions, version information, external assembly references, and other standardized information.

In order for two components, systems, or objects to interoperate with one another, at least one must know something about the other. In COM, this "something" is an interface specification, which is implemented by a component provider and used by its consumers.

In .NET, metadata is a common mechanism or dialect that the .NET runtime, compilers, and tools can all use. Microsoft .NET uses metadata to describe all types that are used and exposed by a particular .NET assembly. Metadata includes descriptions of an assembly and modules, classes, interfaces, methods, properties, fields, events, global methods, and so forth.

.NET assemblies are deployable units and manifests are the metadata that describes the assemblies.

IL Code:

An assembly contains the IL code that the CLR executes at runtime. The IL code typically uses types defined within the same assembly, but it also may use or refer to types in other assemblies. There is one caveat: each assembly can have at most one entry point, such as DllMain( ), WinMain( ), or Main( ). You must follow this rule because when the CLR loads an assembly, it searches for one of these entry points to start assembly execution.

There are four types of assemblies in .NET:

Static assemblies: These are the .NET PE files that you create at compile time. You can create static assemblies using your favorite compiler: csc, cl, or vbc.
Dynamic assemblies: These are PE-formatted, in-memory assemblies that you dynamically create at runtime using the classes in the System.Reflection.Emit namespace.
Private assemblies: These are static assemblies used by a specific application.
Public or shared assemblies: These are static assemblies that must have a unique shared name and can be used by any application.

Side-by-Side Execution:


Manifests: Assembly Metadata
An assembly manifest is metadata that describes everything about the assembly, including its identity, a list of files belonging to the assembly, references to external assemblies, exported types, exported resources, and permission requests. In short, it describes all the details that are required for component plug-and-play. Since an assembly contains all these details, there's no need for storing this type of information in the registry, as in the COM world.

An assembly can be a single-module assembly or a multi-module assembly. In a single-module assembly, everything in a build is clumped into one EXE or DLL, an example of which is the hello.exe application that we developed earlier. This is easy to create because a compiler takes care of creating the single -module assembly for you.

A multi-module assembly is one that contains many modules and resource files. To create it you have to use the Assembly Linker (al.exe) that is provided by the .NET SDK. This tool takes one or more IL or resource files and spits out a file with an assembly manifest.

Any .NET language may be converted into IL, so .NET supports multiple languages and perhaps multiple platforms in the future (as long as the target platforms have a CLR).

The Common Type System (CTS):
Because .NET treats all languages as equal, a class written in C# should be equivalent to a class written in VB.NET, and an interface defined in Managed C++ should be exactly the same as one that is specified in managed COBOL. Languages must agree on the meanings of these concepts before they can integrate with one another. In order to make language integration a reality, Microsoft has specified a common type system to which every .NET language must abide.

Interfaces support exactly the same concept as a C++ abstract base class (ABC) with only pure virtual functions. An ABC is a class that declares one or more pure virtual functions and thus cannot be instantiated. If you know COM or Java, interfaces in .NET are conceptually equivalent to a COM or Java interface. You specify them, but you don't implement them. A class that derives from your interface must implement your interface. An interface may contain methods, properties, indexers, and events. In .NET, a class can derive from multiple interfaces.

The Common Language Specification (CLS):
Microsoft has published the Common Language Specification (CLS). The CLS specifies a series of basic rules that are required for language integration. Since Microsoft provides the CLS that spells out the minimum requirements for being a .NET language, compiler vendors can build their compilers to the specification and provide languages that target .NET. Besides compiler writers, application developers should read the CLS and use its rules to guarantee language interoperation.

CLR Execution:
.Net PE Files(Metadata And IL) >> Class Loader >> Verifier >> JIT >> Managed Native Code

Once the class loader has found and loaded the target class, it caches the type information for the class so that it doesn't have to load the class again for the duration of this process.

The verifier is responsible for verifying that:
1. The metadata is well formed, meaning the metadata must be valid.
2. The IL code is type safe, meaning type signatures are used correctly.

The JIT compilers convert IL to native code so that it can execute on the target operating system. For optimization reasons, JIT compilation occurs only the first time a method is invoked. Recall that the class loader adds a stub to each method during class loading. At the first method invocation, the VEE reads the information in this stub, which tells it that the code for the method has not been JIT compiled. At this indication, the JIT compiler compiles the method and injects the address of the managed native method into this stub. During subsequent invocations to the same method, no JIT compilation is needed because each time the VEE goes to read information in the stub, it sees the address of the native method. Because the JIT compiler only performs its magic the first time a method is invoked, the methods you don't need at runtime will never be JIT compiled. The compiled, native code lies in memory until the process shuts down and until the garbage collector clears off all references and memory associated with the process. This means that the next time you execute the process or component, the JIT compiler will again perform its magic.

If you want to avoid the cost of JIT compilation at runtime, you can use a special tool called ngen, which compiles your IL during installation and setup time. Using ngen, you can JIT-compile the code once and cache it on the machine so that you can avoid JIT compilation at runtime (this process is referred to as Pre-JITting). In the event that the PE file has been updated, you must PreJIT the PE file again. Otherwise, the CLR can detect the update and dynamically command the appropriate JIT compiler to compile the assembly.

All .NET assemblies are essentially binary components. You can treat each .NET assembly as a component that you can plug into another component or application, without the need for source code, since all the metadata for the component is stored inside the .NET assembly. While you have to perform a ton of plumbing to build a component in COM, you need to perform zero extra work to get a component in .NET, as all .NET assemblies are components by nature. Remember, we're using the term "component" as a binary, deployable unit, not as a COM class.

Shared Components:
Unlike application-private assemblies, shared assemblies - ones that can be used by any client application - must be published or registered in the system Global Assembly Cache (GAC). When you register your assemblies against the GAC, they act as system components, such as a system DLL that every process in the system can use. A prerequisite for GAC registration is that the component must possess originator and version information. In addition to other metadata, these two items allow multiple versions of the same component to be registered and executed on the same machine. Again, unlike COM, we don't have to store any information in the system registry for clients to use these shared assemblies.

Object Pooling:
A pool is technical term that refers to a group of resources, such as connections, threads, and objects. Putting a few objects into a pool allows hundreds of clients to share these few objects (you can make the same assertion for threads, connections, and other objects). Pooling is therefore a technique that minimizes the use of system resources, improves performance, and helps system scalability.

ADO.NET Architecture:
Microsoft ADO.NET's object model encompasses two distinct groups of classes: content components and managed-provider components. The content components include the DataSet class and other supporting classes such as DataTable, DataRow, DataColumn, and DataRelation. These classes contain the actual content of a data exchange. The managed-provider components assist in data retrievals and updates. Microsoft provides two managed providers in its current release of ADO.NET: OLE DB and SQL. The OLE DB managed provider comes with OleDbConnection, OleDbCommand, OleDbParameter, and OleDbDataReader. The SQL Server managed provider comes with a similar set of objects, whose names start with SqlClient instead of OleDb. Developers can use the connection, command, and data reader objects to directly manipulate data.

We might think that setting up and tearing down connections is not a good idea since the cost of establishing a connection is usually high. This is a concern only in the absence of connection pooling. ADO.NET automatically keeps connections to a data source in a pool, so when an application thinks it is tearing down a connection, it's actually returning it to the resource pool. This allows connections to be reused, avoiding the cost of reconstructing new connections from scratch.

Because ADO.NET framework classes are managed code, developers can inherit and extend these classes to their custom needs.

A data reader is a new object providing fast, forward-only, and read-only access to data. This is similar to an ADO Recordset with server-side, forward - only, and read-only cursor types. Since this is a server –side cursor, the connection to the server is open throughout the reading of data.

Even though each DataAdapter maps only one DataTable in the DataSet, you can have multiple adapters to fill the DataSet object with multiple DataTables. Managed Code:

Managed Data:

What is an Assembly?
Assemblies are fundamental building blocks of .Net Framework. They contain the type and resources that are useful to make an application. Assemblies enables code reuse, version control, security and deployment. An assembly consist of: Manifest , Type Metadata, MSIL and resource file.

gacutil /i myDll.dll can see and %windir%\assembly

Metadata and Manifest:

Application Domain:

Garbage Collection:

Can .Net Components can be used from a COM?
TlbImp.exe and TlbExp.exe

How does .NET Remoting work?

There are 3 styles of remote access:
SingleCall: Each incoming request is handled by new instance.
Singleton: All requests are served by single server object.



Boxing and Un-Boxing:

.Net Object Oriented Programming Concepts



Object Oriented Programming:







Abstract Class:

What a Class must do, But not how-to.
Describes externally visible behavior of element.

Mean by more than one form. Ability to provide different implementation based on different no./type of parameters. A method behaves differently based on the different input parameters. Does not depend on the Return-Type.



Same as pure-polymorphism.

Identifiers/Access Specifies and scope:
VB.NET: Private, Protected, Friend, Protected Friend, Public.
C#: private, protected, internal, protected internal, public.

What is a Delegate?

Static Variable and Its Life-Time:
VB.NET: Public Shared VAR As Type.
C#: public static Type VAR;
Life time is till the class is in memory.


Called by GC just before object is being reclaimed by GC.


Different Types of Caching?
Output Caching: stores the responses from an page.
Data Caching: is Programmatic way to Cache objects for performance.

Authentication and Authorization:

Different Types of Directives:

Difference between Server-Side and Client-Side:

Difference Server.Transfer and Response.Redirect:

Different Types of Validators and Validation Controls:
RequiredFieldValidator, RangeValidator, RegularExpressionValidator, CompareValidator, CustomValidator, ValidationSummary

How to Manage State in ASP.Net?
Client based: ViewState, QueryString and Cookies Server based: Session, Application.

Difference between User Control and Custom Control:

3 Types of Session State Modes?
InProc(cookieless, timeout),
StateServer (Server, Port stateConnectionString="tcpip=server:port"),
SQLServer (sqlconnectionstring) and Off.

ViewState is a special object that ASP.NET uses to maintain the state of page and all webcontrols/ServerControls within it. It is in this object preserves the states of various FORM elements during post-backs. It is rendered to client(browser) as a Hidden variable __VIEWSTATE under <form>tag. We can also add custom values to it.

What is web.config and machine.config:

Role of Global.asax:

Page Life Cycle:
Init, LoadViewState, LoadPostBackData, Load, RaisePostBackDataChangedEvent, RaisePostBackEvents, Pre-Render, SaveViewState, Render, Unload, (IpostBackDataChangedEventHandler and IpostBackEventHandler) Error, CommitTransaction, AbortTransaction, Abort


ASP.Net List Controls and differentiate between them?
RadioButtonList, CheckBoxList, DropDownList, Repeater, DataGrid, DataList

Type Of Code in Code-Behind class:
Server-Side Code.

Application level variables and settings initialization in App_Start
User specific variables and settings in Session_Start

Difference between inline and code-behind. Which is best?

Which Template must provide to display data in Repeater?

How to Provide Alternating Color Scheme in Repeater?

What base class all Web Forms inherit from?

What method do you use to explicitly kill a user’s Session?


Which two properties are on every validation control?
ControlToValidate and Text, ErrorMessage

How do you create a permanent cookie?
Set expires property to Date.MaxValue (HttpCookie.Expires = Date.MaxValue)




A Web Service can only be written in .NET?

Where on internet would you look for Web services?

How many classes can a single .NET DLL contain?

How many namespaces are in .NET version 1.1?

What is a bubbled event?

Difference between ASP Session State and ASP.Net Session State?

Layouts of ASP.NET Pages:
GridLayout and FlowLayout

Web User Control:

Composite Custom Control:
combination of existing HTML and Server Controls.

Rendered custom control:

Where do you store the information about user’s Locale?

should Validation occur on Client/Server Side for Date Input?


Web Services Discovery:
Even though advertising of a web service is important, it is optional. Web services can be private as well as public. Depending on the business model, some business-to -business (B2B) services would not normally be advertised publicly. Instead, the web service owners would provide specific instructions on accessing and using their service only to the business partner. To advertise web services publicly, authors post discovery files on the Internet. Potential web services clients can browse to these files for information about how to use the web services—the WSDL (Web Service Description Language). Think of it as the yellow pages for the web service. All it does is point you to where the actual web services reside and to the description of those web services. The process of looking up a service and checking out the service description is called Web Service discovery. There are two ways of advertising the service: static and dynamic. In both of these, XML conveys the locations of web services.

Static discovery is easier to understand because it is explicit in nature. If you want to advertise your web service, you must explicitly create the .disco discovery file and point it to the WSDL.

As opposed to explicitly specifying the URL for all web services your site supports, you can enable dynamic discovery, which enables all web services underneath a specific URL on your web site to be listed automatically. For your web site, you might want to group related web services under many different directories and then provide a single dynamic discovery file in each of the directory.

Web Services and Security:
We incorporate security into web service in two ways: system security and application security. System -level security allows for restricting access to the web services from unauthorized clients. It is done in a declarative fashion, whereas application - level security is more flexible. With system-level security, you will most likely have the list of authorized clients' IP addresses that you will let access your web service through the use of some configuration - management tools. With application-level security, you will incorporate the authentication into your web service, thus providing a more flexible configuration.

In system – level security client send a user name and password to web server. This pair can be in plain text format or in some encrypted format. Once server authenticates the user it can access the services available to server.

In application – level security mode your web services involves taking security into your own hands. You can program your web services so that all of their methods require an access token, which can be obtained from the web service after sending in the client's username and password. The client credentials can be sent to the server through SSL (Secure Sockets Layer), which eliminates the risk of sending clear-text passwords across the wire. Through this SSL channel, the server returns an access token to the caller, who can use it to invoke all other web service methods.

Web Form Events


The PreRender event happens just before the page is rendered and sent back to the client. We don't often handle this event; however, it depends on the situation.


Lifecycle Of A Web Form:
In ASP .NET, the web page starts its life when a client requests a particular page. IIS parses and runs the scripts on the ASP page to render HTML content. As soon as the page rendering is complete, the page's life ceases; only the view states of the page persist between requests to the page. These view states allow the controls on the server to appear as if they are still present to handle server events.

Using Web Services:
In Visual Studio.NET IDE, you can choose Project >> Add Web Reference and then type in the URL where the web service resides. For example, we'll point to the web service we created on local server, than is PubsWS (suppose). The URL to this web service on our server is http://localhost/PubsWS/PubsWS.asmx. After adding the web reference, you can access the proxy object to the web service you are calling via the type servername.proxyObjectName. For your case, it is localhost.PubsWS.

The following code excerpt demonstrates how to use the web service through the proxy. We create an instance of the proxy object and then ask it to relay the message to the real web service to get the list of authors. The result will be streamed back in XML format, which is reconstructed into a DataSet object.

localhost.PubsWS ws = new localhost.PubsWS( ); DataSet ds = ws.GetAuthors( );

ASP.NET Session-State Management:
ASP.NET improves upon ASP session-state management by moving to an out-of-process model. By having all web servers in the farm pointing to a common server that hosts the out-of-process state manager, the web client can be redirected around the farm without losing the session states. By using an out-of-process model, we no longer have the problem of losing session states when the IIS process is cycled. This means that if the web server application crashed for whatever reason and restarted within the session time-out duration, the web clients could still have all their session states intact. Of course, if the out-of-process state manager crashed, that is a whole different issue. This leads to the next improvement of ASP.NET—the ability to persist session state to a database.

There are two levels of configuration: machine and application. Machine-level configuration associates with the machine.config file stored in WinNT\Microsoft.NET\ Framework\\CONFIG\machine.config, while the application-level configuration uses the web.config file in the application root directory. The application-level configuration overrides the machine -level configuration.


CCW COM Callable Wrapper
CLI Common Language Infrastructure. This is a subset of the CLR and base class libraries that Microsoft has submitted to ECMA so that a third-party vendor can build a .NET runtime on another platform.
CLR Common Language Runtime
CLS Common Language Specification
COFF Common Object File Format
COM Component Object Model
CTS Common Type System
DNA Distributed interNet Applications Architecture.
DOM Document Object Model
GDI Graphical Device Interface
GAC Global Assembly Cache
GUID Globally Unique Identifier
HTTP Hyper Text Transfer Protocol
IDL Interface Definition Language
IL Intermediate Language
MSIL Microsoft Intermediate Language
MS-DTC Microsoft Distributed Transaction Coordinator
N-Tier Multi-Tier
OLTP Online Transaction Processing
OLAP Online Analytical Processing
PE Portable Executable
RAD Rapid Application Development
RCW Runtime Callable Wrapper
SMTP Simple Mail Transfer Protocol
SOAP Simple Object Access Protocol
TCP Transport Control Protocol
TLB Type Library
UDF Uniform Data Format
UI User Interface
URL Uniform Resource Locator
UDDI Universal Description, Discovery and Integration
WAP Wireless Access Protocol
WSDL Web Services Definition Language
WML Wireless Markup Language
XML Extensible Markup Language


As I have mention earlier that this is a series of articles, this is the first part and I have specified some of the initial concepts related to .NET. In following articles I will go through detailed description of all concepts as well as upations in this article too. As I am still working to prepare it.

Your suggestion and comments will be a great help in improving quality of my articles, please fell free to comment on the stuff.


1. 29 Nov 2005 : Initial Upload.
2. 28 Dec 2005 : Added detailed section on .NET Framework.

Enjoy Development </form>



A list of licenses authors might use can be found here


About the Author

Mukesh Kumar Gupta
Software Developer (Senior)
India India
Currently working as a Senior Developer and enjoying software development from more than 8 years on .NET.

Comments and Discussions

GeneralMy vote of 5 Pinmemberharisofttech12-Jan-13 3:18 
GeneralGreat job and many thanks. [modified] Pinmemberognyandim22-Nov-11 22:24 
GeneralGood topic but should include more concepts PinmemberSastry_kunapuli23-Jul-09 6:19 
GeneralTerrible Advice PinmemberGUI Developer18-Sep-08 3:02 
GeneralRe: Terrible Advice PinmemberSastry_kunapuli23-Jul-09 6:24 
GeneralArticle 1:40 
Generalgood article 0:45 
GeneralA practical solution PinmemberToddHileHoffer12-Feb-08 1:39 
GeneralExtraordinary Article Pinmemberlovelylooney22-Nov-07 17:20 
GeneralFantastic Articles PinmemberChintan.Desai19-Sep-07 23:52 
Thanx for giving brief yet precise knowledge of .NET Framework.Keep it up Smile | :) Big Grin | :-D
(Nothing is so purify as KNOWLEDGE)

GeneralVery nice PinmemberVicky_Edward21-Aug-07 2:51 
GeneralGood idea poorly executed Pinmemberdojohansen19-Aug-07 23:09 
General[Message Deleted] Pinmemberkarthick.n.mca24-Dec-07 2:53 
GeneralRe: Good idea poorly executed Pinmemberdojohansen27-Dec-07 23:35 
QuestionFrom where you got this? PinmemberVikas Parikh19-Aug-07 0:42 
GeneralNice one PinmemberSandeep Akhare28-May-07 3:39 
GeneralCheck this PinmemberSoftwareakash8-May-07 22:17 
GeneralGood Article PinmemberVINH TRAN18-Mar-07 20:30 
GeneralGood article PinmemberNanaAM25-Feb-07 22:36 
GeneralJIT and managed code Pinmemberddecoy12-Oct-06 4:14 
GeneralRe: JIT and managed code PinmemberChintan.Desai19-Sep-07 23:59 PinmemberParul_r9-Oct-06 21:28 
AnswerRe: PinmemberSam's Den10-Jan-07 20:17 
GeneralProcess model and RCW/CCW PinmemberR_raghu16-Aug-06 23:07 
Questionthanks for the input man :) where's part deux ? PinmemberNightJammer20-Jul-06 8:09 



| Advertise | Privacy | Mobile
Web04 | 2.8.140821.2 | Last Updated 26 Dec 2005
Article Copyright 2005 by Mukesh Kumar Gupta
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid