Motta Industries Blog

Hiring a web developer can feel like interviewing a mechanic while the engine is still running. You know the website matters. You may even know what annoys customers. But once the conversation turns to frameworks, plugins, and hosting configurations, it becomes harder to judge whether the proposed work solves your problem.

You do not need to learn programming before the first meeting. You need a way to connect technical choices to business responsibilities: what gets built, how it gets tested, who controls it, and what happens afterward. Treat the interview as a working conversation, not a vocabulary contest.

Begin with the job your website must do

Before speaking with candidates, write a short description of the situation. Explain who uses the site, what they need to accomplish, and where the current experience breaks down. Separate what you have observed from what you suspect.

For example, “People call because they cannot find our service area” is an observation. “We need an interactive map” is a proposed solution. Give the developer the observation first. Ask what they would investigate before recommending the map.

Bring three real tasks to the interview. A customer might need to request a repair, compare two services, or reorder a product. A staff member might need to change a price without disturbing the layout. Choose tasks you can demonstrate rather than broad ambitions such as making the website modern.

A useful candidate will ask about your operations, content, audience, and constraints. They should also identify what they cannot responsibly estimate yet. An immediate answer to everything is less useful than a clear explanation of what needs checking.

Ask for an explanation you can repeat

Try this question: “How would you explain your proposed approach to my office manager?” You are not asking for a sales pitch. You are checking whether the person can communicate decisions to someone who will live with the result.

If an answer is unclear, ask for an example. A capable explanation should let you describe the tradeoff in your own words. You should understand why a choice matters, even if you never touch its implementation.

Review work through decisions, not screenshots

A portfolio shows appearance. An interview should reveal judgment. Ask the candidate to walk through one relevant project and explain the original problem, their actual responsibilities, and the decisions they would make differently today.

For the search portion of the discussion, Google’s guidance on choosing an SEO provides useful questions, including requests for previous work, expected results, and ways to measure success. Those questions also make a practical starting point for evaluating a broader website engagement.

Do not assume the person built everything shown in a portfolio. Ask which parts they designed, developed, wrote, or maintained. A collaborative project is perfectly legitimate; an unclear account of someone’s role deserves another question.

Request a demonstration of a task similar to yours. If your team changes service descriptions weekly, ask to see an editing workflow. If you sell products with complicated options, discuss how those options would be managed. Beautiful screenshots do not answer either question.

Ask permission before contacting a reference, and keep the questions specific. Did the developer explain changes clearly? What happened when requirements changed? Was the handover usable? You are looking for evidence of a working relationship, not a promise that your outcome will match another business’s.

Make ownership and access part of the interview

A website is more than its pages. Ask for a plain inventory of the accounts and services the project will depend on: domain registration, hosting, website administration, email delivery, analytics, and any paid extensions or integrations.

For each item, ask who will hold the account, who will receive renewal notices, and how your business will recover access if the developer becomes unavailable. You do not need to exchange passwords during an interview. You need agreement about responsibility.

ICANN’s registrant responsibilities place responsibility for domain registration and use on the registrant and require current account information. That makes domain administration a business concern, not a detail to leave indefinitely with whoever first registered the name.

Ask the candidate to describe a handover. What documents, account invitations, backups, licenses, and training would you receive? Which subscriptions would remain under someone else’s management? What would you need to pay or arrange to move elsewhere?

Do not accept “you own everything” as a complete answer. Ask what that means for custom code, purchased assets, third-party software, and recurring services. Put the agreed terms in writing, and get appropriate legal advice when ownership language matters to the engagement.

Test the uncomfortable scenario

Ask: “If we stop working together, what happens during the last week?” A professional answer should cover transfer steps, outstanding invoices, access changes, and any practical limits. This is not an accusation. It is ordinary continuity planning for an important business asset.

Ask how quality will be demonstrated

“Responsive,” “accessible,” and “fast” are useful intentions, but they are not an acceptance process. Ask which pages, devices, interactions, and conditions the developer will test. Then ask what evidence you will see before approving launch.

Use your three customer tasks as the starting point. Can a visitor complete the request on a phone? Can someone navigate the form with a keyboard? Does an error explain what needs correcting? Can staff find a submitted inquiry and respond through the expected workflow?

WCAG 2.2, published as a W3C Recommendation in October 2023, is a concrete reference for discussing accessibility requirements. Ask which conformance level and testing methods the proposal includes. Do not treat a tool score or an accessibility label as a substitute for an agreed scope.

For performance, ask how testing will account for realistic content and third-party features. For search, ask how existing useful pages and addresses will be handled. For security, ask who updates software and how recovery would work. Keep each question tied to a responsibility and a deliverable.

You should also understand what is outside the quote. Copywriting, product entry, photography, accessibility remediation, and integration work should not disappear behind an ambiguous word such as setup. A smaller scope stated honestly is easier to evaluate than a generous scope nobody has defined.

Listen for a realistic project process

Ask the developer to describe the first two weeks. What information would they request? What would they inspect? When would you see the first meaningful deliverable? Who would need to approve it?

A sensible plan should include your team’s work as well as theirs. Someone must supply accurate service details, approve wording, answer operational questions, and review the result. Ask how delays in those decisions affect the schedule.

Change is normal. Unpriced change is a source of confusion. Ask how a new request will be documented, estimated, approved, and scheduled. Establish whether a revision changes an existing deliverable or adds a new one. You should be able to understand that distinction before the invoice arrives.

Ask who you will actually work with. Will the person in the interview remain involved? Who handles development, content, testing, and support? If subcontractors participate, how are responsibilities coordinated? You are buying a delivery arrangement, not simply a reassuring conversation with its most polished speaker.

Separate launch from ongoing care

The launch date is a milestone, not a maintenance policy. Ask what happens the next morning, the following month, and when an outside service changes something your site relies on.

Have the candidate distinguish defects in delivered work from new requests and ongoing maintenance. Ask about support hours, response expectations, approval of billable work, and the point at which an emergency becomes a separate engagement. Avoid assuming that every problem is included forever.

Discuss training in terms of the jobs your staff will perform. A useful session might cover changing a service price, replacing an image, reviewing inquiries, and finding help. Ask whether instructions will remain available after the session and how future staff can learn the same workflow.

If you are considering Motta Industries, use the same questions. Review how we approach client work, then ask us to connect that approach to your actual requirements. Familiarity or a friendly meeting should not replace a clear agreement.

Keep the interview safe and proportionate

For an initial conversation, describe the problem without handing over sensitive access. Share screenshots with customer details removed, public page addresses, and a short account of the failing task. If deeper investigation is necessary, agree on its scope before authorizing access to production systems.

Ask how the developer would investigate without interrupting customers. Would they work on a separate test copy? How would they protect information copied from the live website? Who would approve a change before it reaches the public site? These are process questions, not an invitation to diagnose the entire system for free.

Keep a written list of unanswered questions. A candidate who needs to check something can return with a specific answer. What matters is whether that follow-up explains the issue, identifies assumptions, and gives you a decision you can make. An honest limit is more useful than confident guessing, especially when payments, private inquiries, or critical business records are involved. Make room for that honesty when you evaluate the meeting afterward.

Compare answers before comparing totals

After each interview, write a short summary while the conversation is fresh. Record what the candidate understood, what they proposed, what remains uncertain, and what they need from you. Keep their assumptions beside their price.

Use a simple comparison sheet with the same headings for every candidate: discovery, content, design, development, testing, launch, training, ownership, and ongoing care. Mark missing answers as questions rather than filling the gaps with optimistic assumptions.

A higher number may include work another quote excludes. A lower number may be appropriate for a narrower project. Your task is to understand the difference. Ask for revised scope when necessary instead of choosing on a total that describes a different job.

Our website services can help you identify which disciplines your project may involve. You do not need every service. You need the combination that addresses the problem you described at the beginning, with understandable responsibilities attached.

Leave with a clear next step

Before ending the conversation, ask the candidate to summarize the proposed next step, its cost, and its output. That might be a defined assessment rather than a full rebuild. You should know what decision that step will help you make.

Choose the person who makes the work understandable without pretending it is effortless. Good questions do not require you to speak code. They require the developer to explain their reasoning, define their obligations, and respect the decisions that belong to you.

If you want help turning a website problem into a practical brief, contact Motta Industries with the tasks your customers and staff need to complete. Start with those tasks; the technical conversation can follow.