Farm solutions and sandboxed solutions differ in how they are hosted, deployed, and their level of access. Farm solutions are hosted in the IIS worker process and have full trust access, while sandboxed solutions are hosted separately and have restricted access. Deploying farm solutions recycles application pools, while sandboxed solutions do not. Sandboxed solutions are limited in what code they can run for security reasons.

1. Farm Solutions:
- Farm solutions are hosted in the IIS worker process (W3WP.exe).
- If you run any code in farm solution the whole farm will got affected.
- If you deploy any feature or retract any feature the whole application pool got recycled.
- Since they are scoped as farm level, they have full trust access to all the resources.
- When the Sandboxed Solution property is set to False, selecting BuildDeploy will deploy
the solution to the Farm Solution Gallery.
Sandboxed Solution:
- Sandboxed solutions are hosted in the SharePoint user code solution worker process
(SPUCWorkerProcess.exe).
- The process runs under a CAS policy that restricts programmatic access to any resource
outside the sandbox. So it never restart the IIS application pool.
- If you run any code it will affect only the site collection of the solution.
- Helpful if you have shared hosting.
- When the Sandboxed Solution property is set to True, selecting BuildDeploy Solution
deploys the solution to the site collection Solution Gallery.
One major difference in the deployment is Farm solutions are installed and deployed.
Sandboxed solutions are uploaded and activated.
 We can’t create VISUAL web parts in Sandbox solutions.
 We can’t use code to connect to the external web services or to database
 Visual Studio attaches the debugger to the SPUCWorkerProcess process that
the SPUserCodeV4 service in SharePoint automatically triggers and controls
Here the processes which required for Sandbox solutions.
1. SPUCWorkerprocess.exe - Sandbox Worker process service which is a
Seperate Service Application which actually executes Sandbox code. It should
be started in every farm to use Sandbox solutions.
2. SPUCWorkerProcessProxy.exe - Sandbox Worker process proxy which
is working as a proxy for Worker process and takes care of Sandbox code

2. execution. It can also serve to other farms if configured. Basically it helps site
administrator for load balancing.
3. SPUCHostService.exe - Sandbox User Code Service takes care of user
code in Sandbox amd it can be started in the farms where to use Sandbox
solutions.
Sandbox Limitations:
As I said before, Sandbox is a secured wrapper and it has restrictions on code to run in
SharePoint environment. Few key limitations which developers should know are listed
below.
1. No Security Elevation - RunWithElevatedPrivileges which runs the
specified block of code in application pool account(typically System Account)
context is not allowed in Sandbox code. SPSecurity class also not allowed to use
in Sandbox.
2. No Email Support - SPUtility.SendMail method has been blocked
explicitly in Sandbox, However .Net mail classes can be used to send mails.
Additionaly sandbox won't allow to read Farm SMTP address. So developers has
to specify the SMTP address in code itself(may be some other workaround).
3. No Support to WebPartPages Namespace - Sandbox won't allow to use
Microsoft.SharePoint.WebPartPages namespace.
4. No Support to external Webservice - Internet web service calls are not
allowed to ensure security in Sandbox solutions. Allow Partially Trusted code
also can't be accessed within Sandbox.
5. No GAC Deployment - Sandbox solutions are not stored in File
System(Physical path) and assemblies can't be deployed to Global Assembly
Cache(GAC). But it's available on
C:ProgramDataMicrosoftSharePointUCCache at runtime. Note the
ProgramData is a hidden folder.
6. No Visual Webparts - Visual Studio 2010 by default won't allow to create
Visual Webparts to deploy as sandbox solution. But with Visual Studio
PowerTools extensions(downloadable from Microsoft MSDN website) Visual
Webparts can be developed and deployed as sandbox Solutions
Points to be noted:
•One major difference is we can't create Aplication pages in Sandbox solutions.Beacuse Application
pages are stored in the 14TEMPLATES_LAYOUTS and when we deploy as sandbox we dont have
permissions to the physical folder.
•Also we cant create VISUAL web parts in Sandbox soultions.
•We cant use code to connect to the external web services or to database in the sandbox soltion
•Farm solutions are installed and deployed. Sandboxed solutions are uploaded and activated.
• runwithelevatedprivileges doesn't work in Sandboxed solutions.

3. • Site collection adminstrator can deploy a Sandboxed solutions, where as Farm administrator can only
deploy Farm based Solutions.
Users can deploy the below four things as sandboxed soultions :
1. WebParts.
2. Event Receivers.
3. List Definations.
4. Workflows.
Comparison of CAML and LINQ in SharePoint 2010
->Linqisa ObjectorientedQuerylanguage
->LINQis converted toCAML so CAML is betterinperformance butwritingthe queryinLINQiseasier
than CAML
CAML ->query is text based so, if we are joining two lists across a lookup field
there may be various problems associated with that.
CAML->There is no mechanism to know until run time if the query is written
correctly or not. If the query is not correct, then it will simply fail at run time.
Means it won't support at design time
CAML->The query is somewhat difficult to understand. We cannot determine easily
what the query is doing and what lists are being joined.
Linq->The results are returned from queries are strongly typed objects, so the
items and fields can provide compile-time checking.
What is the difference between Classic mode
authenticationand Claims-based authentication?
classic authentication supports NT authentication types like Kerberos, NTLM, Basic, Digest, and
anonymous.
Claims based authentication uses claims identities against a trusted identity provider
in SharePoint2013 by default web app is created as Claims based authentication mode (then
you can choose windows/forms based).
Claim based authentication mode supports the foll:-

4. 1. Windows authentication
2. Forms based authentication.
Visual web parts VS Standard web parts
1. A standard web part is an item-level template in Visual Studio. That means that you can
only add it as an item to your project (an empty SharePoint project for example). A visual
web part can be created as both item-level and project-level.
2. In the case of the visual web part, you can use a designer experience to drag and drop
items on your canvas. In the case of the standard web part, you will have to manually type
everything (using IntelliSense) .
3. A standard web part can be deployed as a Farm or Sandboxed solution. A visual web
part will have to be deployed as a Farm solution.
http://www.randomizzzer.com/2011/06/explained-visual-web-parts-vs-standard-web-parts/
http://crmvoyager.net/2010/11/24/sharepoint-2010-web-parts-vs-visual-web-parts/
ghosting and unghosting in sharepoint
Ghosting: no customization (Data will store in file system)
unghosting: customization of site definition (Data will store in content DB)
Site Content Types
When you create a content type and add it to a site's content type collection, the new content type
becomes available to any child site and also to the site where it was created. For example, if you
create a site content type at the root site of a site collection, that site content type becomes available
on any site in the site hierarchy. If you add a new content type to a site that is lower down in the
hierarchy, it is available in the site where you add it and in any sites below that site in the hierarchy.
We can create site content type inside a Sitecollection ->Site Settings->Designer Galleries-
>SiteContent type
List Content Type
We can create a list content type inside a list->list setting

5. ) What are some useful, OOB features of SharePoint that aid with governance of an environment?
Any of the below are acceptable answers. There are some others but these are the major ones that I
generally look for from a candidate:
Site templates – consistent branding, site structure, and layout can be enforce a set of
customizations that are applied to a site definition.
Quotas – limits to the amount of storage a site collection can use.
Locks - prevent users from either adding content to a site collection or using the site collection.
Web application permissions and policies – comprehensive security settings that apply to all users
and groups for all site collections within a Web application.
Self-service site creation - enables users to create their own site collections, thus must be
incorporated into a governance scheme.
10:There are four predefined routines that take place in a WebPart Life Cycle,
1. OnInit
2. CreateChildControls
3. OnPrerender
4. Render