Question 1
Difficulty: easy
Can you walk me through how you would build a simple responsive landing page from scratch?
Sample answer
I’d start by clarifying the goal of the page, the target audience, and the main action I want users to take. Then I’d sketch a basic layout and build the structure in semantic HTML first, using clear sections like header, hero, features, and footer. After that, I’d style it with CSS using a mobile-first approach so the page works well on small screens before expanding to larger breakpoints. I’d use flexible units, media queries, and maybe CSS Grid or Flexbox depending on the layout. Once the page looks right, I’d test it in multiple browsers and screen sizes, check the text contrast and spacing, and make sure buttons and links are easy to use. If needed, I’d add a small amount of JavaScript for interactions, but only where it adds real value. I like keeping the first version simple, clean, and easy to maintain.
Question 2
Difficulty: medium
What do you do when you run into a bug you can’t solve right away?
Sample answer
When I hit a bug I can’t solve quickly, I try not to guess my way through it. I start by reproducing the issue consistently and narrowing it down to the smallest possible piece of code. Then I use browser developer tools, console logs, and careful code review to see where the behavior changes. If I recently made a change, I’ll compare it with the last working version to isolate the cause. I also check for simple issues first, like typos, wrong file paths, or unexpected data types, because those are easy to miss. If I’m still stuck after a reasonable amount of time, I document what I’ve already tested and ask a teammate for a fresh perspective. I think that approach is efficient because it shows persistence, but it also respects the team’s time. I’ve found that being systematic usually solves the problem faster than random trial and error.
Question 3
Difficulty: easy
How would you explain the difference between HTML, CSS, and JavaScript?
Sample answer
I’d explain it as three different layers that work together to create a website. HTML is the structure and content, so it defines things like headings, paragraphs, images, forms, and buttons. CSS is the presentation layer, which controls how those elements look, including layout, colors, spacing, fonts, and responsiveness. JavaScript adds behavior and interactivity, so it handles things like menus opening and closing, form validation, dynamic content updates, and user actions without a full page refresh. A simple analogy I like is that HTML is the skeleton, CSS is the clothing and style, and JavaScript is what makes the page respond to the user. In a real project, all three matter because a good website needs clear structure, good visual design, and useful interaction. If one layer is weak, the site can feel incomplete or frustrating to use.
Question 4
Difficulty: medium
Tell me about a time you learned a new technology or framework quickly.
Sample answer
In a previous project, I needed to get comfortable with a JavaScript framework I hadn’t used much before, and I had a short deadline. I broke the learning process into small parts instead of trying to understand everything at once. First, I focused on the core concepts like components, props, and state, because those were essential for the task. Then I built a few small practice examples so I could see how the pieces fit together in real code. I also kept notes on common patterns and mistakes, which saved me time later. Once I started the actual project, I used the framework in a very focused way rather than overcomplicating the solution. That experience taught me that I learn best by combining reading, hands-on practice, and immediate application. It also showed me that I can adapt quickly when a project requires a new tool or workflow.
Question 5
Difficulty: easy
How do you make sure your code is clean and easy for others to work with?
Sample answer
I try to write code that is clear before it is clever. That means choosing descriptive variable and function names, keeping functions small when possible, and organizing files in a way that makes sense to someone reading the project later. I also pay attention to consistency, because predictable formatting and naming styles make a big difference in teamwork. When I build something, I think about whether another developer could understand the purpose of the code without needing a long explanation. I also add comments only where they help explain the reasoning, not the obvious parts. Before I finish a task, I usually do a quick review to remove anything unnecessary and make sure the logic is easy to follow. If the team uses linting or formatting tools, I’m happy to follow those standards because they help keep the codebase maintainable. My goal is to make future changes simpler, not harder.
Question 6
Difficulty: hard
Describe how you would handle a task where the design looks good, but the website is slow.
Sample answer
If a site looks good but feels slow, I’d treat performance as a priority rather than an afterthought. First, I’d identify what’s causing the delay by checking load times, network requests, image sizes, and any scripts that block rendering. Large images are often a big contributor, so I’d look at compression, proper file formats, and lazy loading where appropriate. I’d also review CSS and JavaScript to see if there’s unnecessary code loading on the page. If there are third-party scripts, I’d question whether all of them are really needed because those can affect performance a lot. I’d want to balance visual quality with speed, since users care about both. If the page is already in production, I’d make improvements in stages and measure the impact after each change. My approach is to optimize the biggest bottlenecks first so the user experiences a noticeable improvement quickly.
Question 7
Difficulty: medium
How would you debug a form that is not submitting correctly?
Sample answer
I’d begin by checking the basics, because form issues often come from simple problems. First, I’d confirm whether the submit button is actually triggering the form event and whether any validation rules are blocking submission. Then I’d inspect the browser console and network tab to see if the request is being sent and what response is coming back. If the form uses JavaScript, I’d look for event handler issues, missing preventDefault calls, or errors that stop the script before submission. I’d also check the form field names and data format to make sure the backend is receiving what it expects. If the problem is on the server side, I’d review the API response and any validation messages returned by the backend. I like to debug forms step by step because there are usually several possible failure points. That method helps me avoid assuming the problem is in just one place when it could be the result of a small mismatch between frontend and backend.
Question 8
Difficulty: medium
Why do semantic HTML and accessibility matter in web development?
Sample answer
Semantic HTML and accessibility matter because a website should work for as many people as possible, not just users with a mouse and a large screen. Semantic tags like header, main, article, nav, and button give meaning to the content, which helps screen readers, search engines, and other tools understand the page better. That makes the site easier to navigate and improves overall structure. Accessibility also forces me to think about things like keyboard navigation, color contrast, alternative text for images, and proper form labels. Those improvements help users with disabilities, but they also make the experience better for everyone. For example, clear labels and buttons improve usability on mobile devices too. I see accessibility as part of building professional-quality websites, not a separate extra step. If I start with semantic markup and basic accessibility practices from the beginning, I’m less likely to create problems that are harder to fix later.
Question 9
Difficulty: easy
Tell me about a time you worked with a team and had to take feedback on your code.
Sample answer
In one group project, I built a section of the front end and got feedback during review that my code worked, but it was harder to maintain than it should have been. At first, I was a little defensive because the feature functioned correctly, but I realized the feedback was about long-term quality, not just immediate results. I walked through the comments carefully and saw that I had repeated logic in a few places and used names that were too vague. I refactored the code by extracting reusable parts, improving the structure, and making the naming more descriptive. After that, the code was easier for the team to read, and one teammate even used it as a pattern for a similar feature. That experience helped me understand that feedback is valuable, especially early in a career. I try to treat code review as a chance to improve, not as criticism, because the goal is stronger work overall.
Question 10
Difficulty: medium
If you were given a new feature to build with a vague requirement, what would you do first?
Sample answer
If a requirement is vague, I’d start by asking clarifying questions before writing code. I’d want to understand the user goal, success criteria, edge cases, and any technical constraints. For example, I’d ask what problem the feature is solving, how it should behave on mobile, what happens if a user enters invalid data, and whether there are design examples or existing patterns to follow. If needed, I’d also review related parts of the product so I can match the existing experience instead of building something disconnected. Once I have enough information, I’d break the feature into small tasks and confirm the plan with the person requesting it. That saves time later because it reduces rework and avoids building the wrong thing. I’m comfortable working from a rough idea, but I think good communication at the start makes development much smoother and helps the final result meet expectations more closely.
