Web development

What interviewers look for

• Sites that work on a cheap Android phone on slow mobile data, not only on the big screen of your laptop.
• Clean basics: semantic HTML, CSS layout with Flexbox or Grid, and JavaScript you can explain without a framework.
• Knowing the whole path to a live site: domain, DNS, hosting, SSL, business email and backups.
• Security habits for forms, logins and WordPress: updates, strong admin passwords, and checking data on the server.
• Working with non-technical clients: turning “make it modern” into a clear list of pages, content and a deadline.
• Live work they can open on their own phone during the interview, with your exact role in each project.

Questions they ask

1. 1“How do you make sure a website works well on mobile phones?”

   Why they ask: Most visitors here use phones on mobile data. The panel checks that you design for them first, not as an afterthought.

   How to answer

   • Mobile-first CSS: the viewport tag, flexible layouts, and media queries for bigger screens.
   • Light pages: compressed images, few scripts, and fonts that load quickly.
   • Test on a real, cheaper phone and with the network slowed down in DevTools.

   I build mobile-first. I write the CSS for a small screen, then add media queries for larger ones, and use Flexbox or Grid so nothing has a fixed width. Images are compressed to WebP and never wider than their container. For a school website in Hargeisa, most parents opened it on phones, so I tested it on a basic Android phone and in Chrome DevTools on slow 3G. The first version was too slow, so I made the main image smaller and removed a slider plugin.

2. 2“A client says their website is slow. What do you check, and in what order?”

   Why they ask: It tests whether you measure first and fix the biggest cause, instead of guessing or rebuilding everything.

   How to answer

   • Measure with PageSpeed Insights or Lighthouse and the Network tab before changing anything.
   • Fix the heaviest items first: usually images, then extra scripts and plugins, then caching.
   • Check the hosting last, and measure again to show the client the difference.

   I measure before I change anything. I run PageSpeed Insights and look at the Network tab to see what is heavy. On a hotel site I worked on, the home page had photos straight from a camera, several megabytes each. I resized them, converted them to WebP and lazy-loaded the ones lower on the page. I also removed two plugins nobody used and turned on caching. Then I measured again, so I could show the client the before and after.

3. 3“Explain how you would build a contact form, from the HTML to where the message ends up.”

   Why they ask: A form touches everything: HTML, validation, the server, email, spam and security. It shows whether you see the full path.

   How to answer

   • Proper HTML: labels, the right input types, required fields and a clear error message.
   • Validate in the browser for the user, and again on the server, because browser checks can be skipped.
   • Send or store the message safely, stop spam, and keep any email password on the server only.

4. 4“A business asks you for a website. What do you need from them, and how do you put it online?”

   Why they ask: It checks project sense and hosting knowledge together: requirements, content, domain, DNS, SSL and a clean handover.

   How to answer

   • Agree the goal, the pages, who will update it, and a date for the content.
   • Register the domain in the client's name, point DNS to the hosting, install SSL, set up email.
   • Hand over logins, a short guide and the renewal dates, and agree who does updates.

   First I ask what the site must do: which pages, who will update them, and whether they need a form or a WhatsApp button. I collect the logo, photos and text early, because content is usually what delays a project. Then I register the domain in the client's name, point the DNS to the hosting, install a free SSL certificate and set up business email. At handover I give them the admin login, a one-page guide, and a note of when the domain and hosting renew.

5. 5“When would you use WordPress, and when would you build with React or plain code?”

   Why they ask: They want judgement, not a favourite tool: who will maintain the site, what it must do, and the budget.

   How to answer

   • WordPress: content sites the client edits themselves, news, blogs and small shops.
   • React or a framework: interactive apps with many screens and states, such as dashboards or booking systems.
   • Plain HTML and CSS: a small, fast site that rarely changes.

6. 6“In React, what is the difference between props and state?”

   Why they ask: A basic React check. They want a short, correct explanation with a simple example from a real screen.

   How to answer

   • Props are passed in from the parent component and are read-only inside the child.
   • State belongs to the component; when it changes, React draws the component again.
   • Example: the cart count is state in the page and passed as a prop to the header badge.

7. 7“A WordPress site you look after has been hacked and shows spam links. What do you do?”

   Why they ask: They check you stay calm, clean it properly, tell the client honestly, and stop it happening again.

   How to answer

   • Keep a copy as it is, then change every password: WordPress, hosting, database and FTP.
   • Restore a clean backup or clean the files, update everything, remove unknown users and unused plugins.
   • Tell the client plainly, then add updates, two-factor login and off-site backups.

   First I make a copy of the site as it is and put up a maintenance page. Then I change every password: the WordPress admin, the hosting, the database and FTP. I restore the last clean backup, update WordPress, the theme and all plugins, and delete plugins and admin users that should not be there. I tell the client plainly what happened and what I changed. After that I set up automatic updates, two-factor login and daily backups stored outside the server.

Example answers are in English, the language most panels use. Say it in your own words.

Topics to revise

• Semantic HTMLUsing the tag that matches the meaning: header, nav, main, button, label. It helps screen readers, search engines and other developers. They may ask why a <button> is better than a <div> with a click handler: it works with the keyboard and screen readers by default.
• CSS Flexbox and GridFlexbox arranges items in one direction, like a row of buttons or a menu. Grid handles rows and columns together, like a gallery of cards. A common task: centre a box on the page, or make three columns that become one column on a phone.
• Responsive design and media queriesThe same page adapts to any screen. You need the viewport meta tag, relative units (%, rem), images limited to their container, and media queries such as min-width: 768px. Mobile-first means you write the phone layout first and add rules for bigger screens.
• JavaScript: DOM, events and fetchThe DOM is the page as JavaScript sees it. You select elements, listen for events with addEventListener, and change content. fetch with async/await calls an API. A typical question: open and close a mobile menu on click, or load a list from an API with a loading message.
• React: components, props, state and hooksA component is a reusable piece of the screen. Props come from the parent; state lives inside and changes over time with useState. useEffect runs code after render, for example to load data. Lists need a unique key for each item. Expect to explain one component you wrote.
• Web performance and Core Web VitalsSpeed is mostly images, scripts and caching. Core Web Vitals are Google's measures: LCP (how fast the main content appears), CLS (whether the layout jumps) and INP (how fast the page reacts to a tap). Tools: PageSpeed Insights, Lighthouse, the Network tab.
• Domain, DNS and hostingThe domain is the name, hosting is the server that runs the site, and DNS connects them. An A record points the name to the server's IP address, a CNAME points to another name, MX records decide where email goes. Changes can take hours to spread. Classic question: why did email stop after moving the site?
• HTTPS and SSL certificatesAn SSL/TLS certificate encrypts the traffic between the browser and the server and shows the padlock. Let's Encrypt certificates are free but must renew automatically. Redirect all HTTP to HTTPS, and fix “mixed content”: images or scripts still loaded over HTTP.
• Form security (validation, XSS, CSRF, spam)Never trust what a form sends. Validate on the server, escape anything you show back on the page (to stop XSS), use CSRF tokens on logged-in forms, and protect against spam with a hidden honeypot field or a CAPTCHA. They may ask what XSS is in one sentence.
• WordPress: themes, plugins, updates and rolesThe theme controls the design, plugins add features, and a child theme keeps your changes safe during updates. Fewer, well-known plugins means fewer security holes. Give staff the Editor role, not Administrator. They may ask how you back up and update a live site safely.
• Accessibility basicsSites that everyone can use: alt text on images, enough colour contrast, labels on every input, and a page that works with the keyboard only. NGO and UN clients often ask for it. A quick test: can you fill the form using only the Tab key?

Practical tasks you may get

1. 1Build a page from a design in 60 to 90 minutes, for example a landing page from a Figma file or a screenshot. Start with the phone layout, use semantic HTML, get the structure right before small details, and check it at phone width before you hand in. Practise by rebuilding two real landing pages from screenshots.
2. 2Fix a broken or slow page: they give you a page with layout bugs or a slow load. Open DevTools, inspect the element, read the Console for errors and the Network tab for heavy files, and explain each fix out loud.
3. 3A small JavaScript or React task: load data from a public API and show it as a list with loading and error states, or a simple to-do list with add and delete. Practise both in plain JavaScript and in React until you can do them without a tutorial.
4. 4WordPress task: add a page, install a form plugin, make the contact form deliver to an email address, and explain how you would secure and back up the site. Practise on a local WordPress install before the interview.

Portfolio questions

• Show three or four live sites, each with a link that works on a phone, your role (design, build, hosting) and the tools. A site for a real small business beats a tutorial copy.
• Check every link the day before. Expired domains and SSL warnings are common on old portfolio sites, and the panel will open them on the spot.
• Say clearly what you built and what came from a theme or template. “I customised a ready theme and built the booking form myself” is honest and acceptable.
• Keep at least one project written from scratch on GitHub, so the panel can see your code and not only WordPress work.

Mistakes to avoid

• A portfolio that only looks good on a laptop. The panel will open it on a phone.
• Calling yourself full-stack after one tutorial. They will ask about the server and the database.
• Checking a form only in the browser. Anyone can skip browser checks and send bad data.
• Registering the client's domain in your own name or keeping the only admin login, so the client cannot leave you.
• Installing many WordPress plugins and never updating them.

Quick check

5 questions. Answer each one to see the explanation.