A guide to hiring a SharePoint developer
SharePoint is the Microsoft product many companies use for intranets, team sites and shared files. Most people meet it as SharePoint Online, part of Microsoft 365. A SharePoint developer shapes it to fit how your business works. That can mean a clear structure and good permissions, a custom web part built with code, an approval flow, or a careful move from an older version. If staff say they cannot find anything, or your SharePoint grew without a plan, a specialist can turn that around.
What a SharePoint developer actually owns
The role covers much more than building pages. A SharePoint developer plans the site structure, sets up document libraries and decides how files are described and found. They set permissions so that the right people can see the right content. They build custom web parts and extensions when the built-in ones are not enough, and they connect SharePoint to flows and other services. They also write the short rules that keep a site tidy, since a clever build still fails if nobody knows how to use it.
SharePoint Online and the SharePoint Framework
For custom screens, Microsoft offers the SharePoint Framework, usually called SPFx. It is used to build web parts and extensions with modern web tools. Most teams write SPFx work in TypeScript, and many use React. A developer who knows these tools can build a news feed, a directory or a small dashboard that sits on a SharePoint page and looks like it belongs. They also know how to package the result so an administrator can add it safely.
Intranets and team sites
An intranet is a home for news, policies, forms and links. A good one is simple. Staff open it, see what matters today and find the thing they came for. A team site is smaller, built around a group and its files. A developer helps you decide which you need, sets up the navigation and page layouts, and shows editors how to publish without breaking the design. Plain choices usually beat clever ones here.
Document libraries and metadata
A library is more than a folder. It can hold columns that describe each file, views that group and filter, and rules that set who can edit. Metadata lets people find a file by what it is, not by where someone put it. The trick is balance. Too few columns and search is poor. Too many and people skip them. A developer picks a short set that matches how your teams talk about their work.
Permissions and governance
Permissions are where many sites go wrong. Access that was set one file at a time soon turns into a maze that nobody understands. A better habit is to use groups and keep inheritance simple. Governance is the set of agreed rules about who creates sites, who owns them and when old ones are closed. A SharePoint developer can build the setup, but you need a named owner for the rules afterwards.
Power Automate and Power Apps
Power Automate runs flows, such as sending a document for approval or reminding a person when a task is late. Power Apps builds simple forms and apps on top of your data. Both connect easily to SharePoint lists and libraries. They are good for routine steps and small tools. A developer can tell you when a flow is enough and when the job needs real code, for example a web part or a Microsoft developer building a service in C# and .NET.
Microsoft Graph
Microsoft Graph is the interface Microsoft provides for data in Microsoft 365, such as users, groups, files and calendars. A web part can call it to show a person’s upcoming events, or a service can use it to create sites in bulk. The main care points are permissions and error handling. Ask a candidate which access a feature really needs and how they would handle a failed call.
Moving from an older SharePoint
Many companies still carry an older SharePoint with years of files and custom code. A move to SharePoint Online starts with a review. What is still in use, what can be archived and what must be rebuilt? Old custom code often cannot move as it is and needs to be rewritten with modern tools. A good developer plans a test run, checks links and permissions after the move and keeps a rollback plan in case the first attempt shows problems.
How a SharePoint developer differs from other roles
A Microsoft developer works in C#, .NET and Azure and builds apps and services. A front-end developer builds screens in the browser and may build SPFx web parts too. A TypeScript developer knows the language that SPFx uses. A SharePoint developer ties these skills to the product itself: sites, libraries, permissions and the way staff use them. Choose that depth when SharePoint is central to how your company works.
The jobs people hire for
One common brief is a new intranet, or a rebuild of one that nobody likes. Another is a clean up of a site that grew without a plan, with too many libraries and unclear access. A third is a move from an older SharePoint, and a fourth is a custom web part or flow that the built-in tools cannot provide. Each brief needs a slightly different mix of skills, so say which one you have.
When a SharePoint developer makes sense
- Your company already runs on Microsoft 365 and files and news live in SharePoint.
- Staff cannot find documents, or the same file exists in many places.
- You need a web part, a form or a flow that the standard tools do not offer.
- You are still on an older SharePoint and need a safe plan to move.
- Access rules have become hard to understand and you want them fixed.
If you only need a place to share files with a few people, the built-in features may be enough. Hearing that from a developer at the start is a good sign.
Reading a SharePoint developer’s background
Ask for a site or a web part they built and still know well. Look at how the navigation works, how libraries are set up and how access is handled. Listen for why they chose that structure, what went wrong and what they would do differently today. A list of product names tells you little, because anyone can write SharePoint on a resume. The better test is whether staff were still using the site long after launch.
Interview questions to try
- How would you decide between a new site and a new library?
- How do you set up permissions so they stay simple as the company grows?
- When would you build an SPFx web part, and when would you use what is built in?
- How would you plan a move from an older SharePoint?
- What would you check if staff said search was not finding their files?
The best answers give reasons and a real example from past work. Be wary of a candidate who answers every question with a custom build and never mentions the built-in options.
Run a small paid exercise
Give each finalist the same small task from your real list of work. It could be designing a library for one team, writing a small web part or planning the move of a single site. Pay for the time. Then compare the plans, the questions asked and how clearly each person explains the result.
Agree how the work is kept healthy
Agree how changes are tested before they reach staff, who approves them and where the code is stored. Ask for a short note on each custom web part that says what it does and how to deploy it. Keep your Microsoft 365 tenant, your code repository and your keys in your own name, with a separate login for each person. Then nothing is lost if the people change.
Settling in
Show your developer the sites staff use most and the ones they grumble about. A weekly call and one shared task board keep progress easy to see. Raise the odd cases early, such as a site with strange access or a flow that fails now and then, because fixing those is what a SharePoint specialist is for.
Mistakes to avoid
- Building custom code when a built-in feature would do.
- Setting permissions one file at a time.
- Moving old content without cleaning it up first.
- Leaving no owner for the site rules after the project ends.
For related skills, see our Microsoft developers for C#, .NET and Azure work, or our JavaScript developers for code that runs in the browser.