Aydınlatma metni yükleniyor…
Choosing a web developer based only on programming languages, frameworks or the visual quality of a portfolio can be misleading. A corporate website, customer or dealer portal, e-commerce system or ERP-connected platform demands more than the ability to write code. The delivery team must understand business rules, design an appropriate data model, enforce user permissions, manage integration failures and hand over a system that can be operated and maintained.
A technical evaluation should therefore be more than a quiz about syntax or memorised concepts. Its purpose is to reveal how an in-house developer, freelancer or software agency analyses a real requirement, explains technical decisions and demonstrates that its work will remain secure and sustainable. The following framework gives HR, IT, product, digital transformation and procurement teams a shared basis for comparison.
Clarify the project context before the technical evaluation
A useful interview begins with a well-defined scope. Questions such as “Do you know React?” or “How many years have you used PHP?” rarely predict project success on their own. First identify the users, critical transactions, data sources, integrations and operating conditions. In a dealer portal, for example, dealer administrators, sales representatives and finance users may need different access to the same records. If inventory comes from an ERP, you must also establish where orders will be written and what should happen when either system fails.
Give every candidate the same concise project brief, including the objective, scope, assumptions, known constraints and expected output. If these details are unavailable, prepare a requirements document before beginning recruitment or supplier selection. Ambiguity itself can produce valuable evidence: the strongest candidate is not necessarily the one who makes the most assumptions, but the one who identifies uncertainty and asks the right questions.
A five-stage process for evaluating web developers
Trying to assess communication, architectural judgement and code quality in one conversation produces inconsistent results. Use a staged process in which each step generates a different form of evidence. Adjust the depth to the role and seniority, while keeping the scenario and scoring principles consistent across candidates.
1. Share the business scenario and success criteria
Instead of disclosing an entire live project, provide a limited, anonymised scenario: “Corporate customers select products and request quotations; prices come from the ERP; a sales manager approves each request.” The expected response need not be a working product. Ask for discovery questions, a core workflow, principal risks and a proposed approach. This shows whether the candidate analyses the problem before prescribing technology.
2. Evaluate the discovery questions
Strong candidates ask about user roles, data ownership, transaction volumes, personal data, failure states, existing infrastructure and release responsibility. Questions such as “How current must stock information be?”, “Should an order be queued when the ERP is unavailable?” and “Does approval authority vary by order value?” demonstrate attention to the real workflow. An immediate focus on frameworks may indicate that operational requirements are being overlooked.
3. Test the architectural approach through discussion
Ask the candidate to sketch the relationship between the interface, application layer, database, integrations and external services. Then introduce a condition that could change the design: transaction volume grows tenfold, the ERP becomes slow or a new user role is introduced. You are not looking for one fashionable architecture. Look for an ability to explain trade-offs and distinguish necessary engineering from avoidable complexity. For custom platforms, Kumsal Agency’s web development approach similarly considers business processes, roles, data and integrations together.
4. Use a bounded practical task and code review
Select a small but representative part of the work. Role-based access control, retrieving data from an external service, recording an error and writing several tests will usually reveal more than an abstract algorithm puzzle. Keep the exercise achievable within two to four hours, and state the time limit and submission expectations in advance. Do not use candidates to complete unpaid production work; if broader validation is necessary, commission a paid pilot.
5. Score evidence and verify it through references
Each evaluator should score predefined criteria independently and record observed evidence. Replace “seems senior” with notes such as “explained queueing, retry limits and reconciliation for an ERP outage.” During reference checks, ask about delivery discipline, responses to review feedback, handling of production incidents and technical handover. This lets you compare interview performance with past working behaviour.
Which capabilities should a technical interview assess?
Build the interview around the project’s risks. A content-led corporate website may place greater weight on content management, performance and accessibility. A customer portal should emphasise authorisation, audit records and integration resilience. The following areas provide a practical common core.
Translating business requirements into a technical model
Ask the candidate to turn a request into user stories, data fields, states and acceptance criteria. For “dealers must be able to place orders,” how will product availability, dealer-specific pricing, credit limits, approval, cancellation and ERP submission work? A good answer identifies unresolved points, separates business rules from technical choices and recommends sensible boundaries for the first release.
Architecture and data design
Explore why the data model is structured in a particular way, how modules are separated and how dependencies are controlled. Candidates should be able to discuss migration, backward compatibility and growth—not only ideal operating conditions. Avoid rewarding complexity by default: a modular monolith may be more appropriate than distributed services when the product, team and operating scale do not justify them.
Security and personal-data handling
Ask candidates to distinguish authentication from authorisation, identify where access rules must be enforced, explain how secrets are stored and describe input validation. Naming a security product is not enough. They should explain, for example, how the system prevents one dealer from viewing another dealer’s order by changing an identifier in a URL. The NIST Secure Software Development Framework provides a common basis for incorporating secure practices into the software lifecycle and supplier relationships.
Integration and failure management
For ERP, CRM, payment or shipping integrations, discuss timeouts, duplicate requests, partial success and inconsistent records as well as the successful path. Depending on the requirement, a robust answer may include idempotency, bounded retries, queues, logs, alerts and a manual correction route. In ERP-connected work, enterprise resource planning is not merely an API connection; it requires clear data ownership and reconciliation between systems.
Testing, release and operations
Candidates should explain which behaviours belong in unit, integration or end-to-end tests. Ask about configuration management, staging environments, database migrations, rollback, logging, monitoring and backups. Working code is not a complete delivery. Another team must be able to release, observe, recover and maintain it without relying on undocumented knowledge.
How to design a practical technical assignment
The task should represent the role without consuming disproportionate time. Give candidates applying for the same role an identical brief, time allowance, starter data and assessment criteria. State whether external resources are permitted and how AI-assisted tools must be disclosed. Rather than treating tool use as the deciding factor, assess whether candidates can explain and verify the resulting code and accept responsibility for it.
A suitable back-end assignment might be a small quotation-request service with two user roles. Ask for a data model, two API endpoints, authorisation, validation responses and tests for critical behaviour. The README should include setup instructions, assumptions and work required before production. For a front-end role, use the same scenario but add an accessible form, loading states, useful error messages and responsive behaviour.
Score functional correctness, readability, security, testing, failure handling and clarity of decisions. Pixel-level details or personal style should not dominate unless they are genuinely central to the role. A candidate who identifies unfinished work, prioritises it and explains the consequences may show stronger scope management than one who hides gaps.
Evidence to look for during code review
Code review should not be reduced to whether the code “looks clean.” Begin by checking whether the change meets the user requirement, then examine its design, data, security, testing and operational effects. Google’s code review guidance recommends considering design, functionality, complexity, tests, naming, comments and documentation together.
Readability and responsibility boundaries
Do function and class names communicate intent? Are business rules scattered across controllers, interfaces and data-access code? Is logic duplicated? Has the solution been complicated with abstractions for speculative future needs? Ask the candidate to justify one design choice and compare it with a credible alternative.
Security controls
Review input validation, server-side authorisation, handling of sensitive data in logs, safe error responses, dependencies and secret management. Automated scanning is useful, but it cannot independently understand every business-logic flaw or misplaced permission boundary. The OWASP Secure Code Review Cheat Sheet explains the role of manual review in examining data flows, authorisation, business logic and trust boundaries.
Quality of the tests
Do not judge quality only by test count or coverage percentage. Check whether a test genuinely fails when the behaviour is broken, verifies an important rule and avoids unnecessary reliance on external services. In addition to the happy path, look for unauthorised access, invalid input, timeouts and duplicate requests.
Operability and technical handover
Confirm that configuration is separated from code, logs and error identifiers are useful, and database changes have a safe rollback or recovery strategy. Setup instructions, environment requirements and known limitations should be documented. Before appointing an agency or freelancer, clarify ownership of repositories, domains, hosting, third-party accounts, licences and release permissions.
Compare candidates with a shared scorecard
Adjust scorecard weights to the project. An ERP-connected portal may prioritise requirements analysis, data security and integration resilience; a content-heavy corporate website may give more weight to accessibility, performance and manageability. Define observable behaviours for each score from one to five. One might mean the candidate missed the risk, three a workable baseline, and five an evidence-based explanation of trade-offs and operational impact.
Agree on red flags before interviews begin: prescribing technology without understanding the problem, enforcing permissions only in the interface, dismissing testing, concentrating all access in one person, using production data without controls or treating handover documentation as unnecessary. Conversely, one syntax error or a different formatting preference should not trigger automatic rejection.
| Capability | Strong evidence | Risk indicator | Suggested weight |
|---|---|---|---|
| Requirements analysis | Asks about roles and exceptions | Proceeds on assumptions | High |
| Architecture | Explains trade-offs | Imposes a technology | Medium/High |
| Security | Enforces access on the server | Relies only on the interface | High |
| Testing and operations | Plans for failure and recovery | Shows only the happy path | High |
| Handover and communication | Documents ownership and access | Keeps access tied to individuals | Medium/High |
Should you evaluate in-house developers, freelancers and agencies in the same way?
The core standards remain consistent, but the scope of responsibility changes. For an in-house developer, assess collaboration with the existing team, long-term ownership of the codebase and the ability to build organisational knowledge. For a freelancer, also examine availability, capacity, continuity arrangements and the conditions for transferring work to another specialist.
When evaluating a software agency, confirm whether the people in the sales meeting are the team that will deliver the project. Establish ownership across analysis, UX, development, testing, DevOps and project management, and ask how continuity is maintained when personnel change. Review the agency’s code-review standard, release process, security practices and handover system—not only one polished code sample.
Connect the selection decision to sustainable delivery
The best web developer is not necessarily the person who answers every question fastest. A stronger choice may be the candidate who uncovers the business problem through precise questions, makes risks visible, chooses a sufficiently simple solution and integrates security and testing into everyday delivery. Compare candidates using the same scenario, criteria and recorded evidence—not a technology checklist, attractive portfolio or low headline price.
Evaluate your workflows, user roles, data and integration requirements with Kumsal Agency. By defining the scope and technical expectations together, you can create a sustainable development roadmap for a corporate website, e-commerce platform, customer or dealer portal, or ERP-connected custom application.