Professional development

Top 30 Web Developer Interview Questions and Answers for 2019

Kurt Ellzey
December 19, 2018 by
Kurt Ellzey

"Do what we say, or we shall replace you with a very small shell script." It's a bit of a dated threat now, but in the age of extreme optimization there are certain functions where it absolutely is a possibility. But who's going to be the person writing that script? You! Web development is an amazing field, with potential as far as the eye can see.

The flip side of this potential is that preparing for an interview as a Web developer can be seriously challenging if the organization you're applying for isn't 100% in your wheelhouse. Going over the questions listed in this article can give you a great start on preparing for that interview, as well as showing you that you're very likely more prepared than you think.

What should you learn next?

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Level 1: A Funny Thing Happened on the Way to the Keyboard

1. What do you do?

One of the most basic questions, and yet in the case of Web development, one of the most varied. This particular specialization can cover a mountain of potential tasks, so being able to answer what you do on a daily basis without giving specifics is something to give some thought.

2. How would you begin to troubleshoot a problem?

"Hello?"

"Ahh! Ahh! This mission-critical application isn't working and I'm not about to give you any specific error codes or actions that are happening but you've gotta fix it right now! Thanks, bye!”

So this is the part where some people would give up, while others would try to figure out what in the world is actually going on. Gathering and receiving the right information at the very beginning of a problem is one of the most overlooked sections of troubleshooting, yet it can cause ripples of delays across the entire project. For example, if an issue isn't assigned to the proper department because a specific question wasn't asked during case intake, it could translate into days of re-routing to the correct person.

3. Why is it a good long-term play idea to split coding and styling?

While the official line on this is to be able to keep a more consistent look and feel regarding a particular project, a more basic reason for it is "something you don't have to do yourself." For example: Say it's been several years since a site went live and Management feels like it's due for a refresh. As long as most of the individual pages stick to the rules you've specified in the CSS, this means that color, fonts, images and in some cases complete layouts across the entire site can be changed without you having to ever having to get involved.

4. How/Do you manage your source?

Unfortunately, the "Do you manage your source?" question is a lot more popular than it should be among some of the people I know. Of course, there are dozens of ways to manage your code across hundreds of possible vendors, yet the process of “Saving code where people working on these projects later can find it” is still a challenge for some developers.

5. What is your method of QA?

Do you manage it from start to finish? Do you hand off the code to a dedicated QA department and they run it through the wringer? Do you post the site to a test environment and then have regular users try to break it? Do you have an idea for managing this that may be better than what the organization does at the moment? Proper QA is vital for development, and sadly, projects are often pushed through in the name of getting it out the door. (“That paragraph is poorly-written.” “Yeah, well, we’ll patch it later.”)

6. What resources do you use when looking for solutions?

Every major platform combination has resources online to be able to assist with projects. Whether they are officially sanctioned like Microsoft's own resources or community-driven like StackOverflow or walkthroughs on YouTube, there are areas on the Web that suit nearly all styles of learning.

7. What is your preferred working environment?

Starbucks. The couch. The beach. Next to the pool table. The office at midnight with the shades closed, with the entire rest of the staff having gone home for the night and you having the whole floor to yourself. Every single person has their own place to think, and their own way of getting into the zone. Sometimes the organization can assist with this, while other times they just need to get out of the way. Whatever methods you have to get your project finished and on time, they'll want to know about it.

8. What's your process for starting a project from scratch?

Project Scope. The two magic words that are simultaneously a nightmare-inducing responsibility and a shield against "Hey, you know what would be a good idea?" Feature creep can give even the best developers monster headaches, so laying out from the get-go what this thing is, what it needs to do and when it needs to be done by are absolutely mandatory. From here, it's open season — whether you want to knock out the easy parts first, copy over stuff you've made in the past that's just about done or start building your test rig, so you are ready to roll when the project is ready, it’s up to you.

9. How do you document your code?

Ah, documentation. If there is one thing that is more difficult than trying to get people to use source control, it's documentation. "I don't know why you want me to do this. It makes perfect sense to me. Anybody else should be able to work it out immediately." This statement, while true at the time, can be absolutely infuriating when you have to come back to your own code five or ten years down the line. You end up staring at line after line of sludge and think: "What in the world was I thinking?"

Inline comments, readmes or full-blown volumes of guides can be tremendous time-savers for yourself and others, depending on the scale of your project. Just be sure to try to use a language filter if you plan on leaving notes where nobody else should ever see them. It didn't work out so well for Windows developers back in the day.

10. Have you ever had to migrate an application from one server type to another?

Your organization has very specific rules about what languages they use, what server types are allowed, and who runs the show when it comes to creating new applications. So imagine the surprise when you come in Monday morning to find out that another department has been running a "sanctioned" site for years, has potentially sensitive data on there and has more viruses than a CDC storehouse. It's now your job to migrate that over to company servers and standards. Doesn't that sound like fun?

Level 2: "It is by caffeine alone I set my mind in motion"

11. You're working on an application where the criteria may change rapidly. What would you do to help not have to start from scratch every time?

Let's face it: Having things change on you when you're in the middle of a project is frustrating, no matter when it happens. Still, there are certain ways to make sure that you can still salvage some code, regardless of what happens with the rest of the project. Saving out these core elements as snippets and templates can not only make it so that you don't feel like your time has been completely wasted, but also have the potential to make every project beyond that go just a tiny bit faster in the future.

12. At some point, we will have an emergency situation come in where a developer needs to stop what they're doing on their own project and start examining why another one is broken. Will this be a problem?

This, honestly, is not something for everyone. Sometimes when you get into the zone on a project, you need to remove all other distractions in order to keep going along that train of thought. The idea of having to stop and change gears to a completely different track can be so aggravating that some people just refuse it outright. This is a concept that not only will come up, but it is one that you need to seriously think about to see if you can handle it.

13. We make sure that our applications work properly on one browser and on one operating system. What do you think of this?

Supported platforms are a bit of a tricky element. On the one hand, if you're working on an application that is only ever to be used in-house, on a specific set of criteria, it may not be a big deal. However if you're dealing with an application with a reach well outside of the company's employees … Not so much. Context is everything when it comes to this sort of question and specifics are needed to give a proper answer.

14. We've got a developer that posts completed code to live immediately upon completion. What do you think of this?

"Oh sure, we'll just post it to live at midnight on a Friday. It’s fine, nobody will notice."

For those of you that have been awake until 4 AM trying to figure out what phantom crawled into your network, I sympathize. "Pushing to Live" with untested, unproven code is universally frowned upon, although the level it is disliked can vary tremendously from organization to organization. This doesn’t mean that it doesn't have its merits in emergency cases where it is absolutely unavoidable, and yes, eventually you have to bite the bullet and deploy in every situation regardless of how much you’ve tested. Still, keeping the rest of the team in the loop goes a long way to making sure that they are prepared to support your projects.

15. You've learned Language X, and we currently use Language X. We're thinking about going to Language Y — what do you think, and would you be able to learn it?

Time marches on, and in Web development, it marches to a bit of a faster beat than most places. A language that was cutting-edge two years ago may be obsolete in less than six months. In order to keep progressing (even though it may be difficult) and if the organization is going to assist with paying to learn a new skill — it might be worth taking the chance. However, if the reason they are thinking of changing is just for the sake of change, and then perhaps change again later down the pipe, you might want to look at some of the applications you'd be asked to support to see if this is their standard M.O.

16. You've been given a legacy Web app that was written by someone that is no longer with the company. How do you wrap your head around it?

While this isn't necessarily a big deal for organizations with high turnover rates, if one person has been there forever, knows everything and is always the one that fixes large number of esoteric issues then suddenly is no longer there? Big problem. That is, unless you're taking over their responsibilities and were able to either learn enough about their coding style to get into their heads, or they were very good at documentation. If neither of these is the case, you could be in for a monster headache.

By the way, if you take away one thing from this article? Document everything.

17. For database back-ends, I see you’ve dealt with Brand X. We only work with Brand Y. Is this a problem?

There are always positives and negatives when comparing software packages. Sometimes one runs faster than the other, while other times, this one has one specific function that is critical to this organization's particular implementation of it. At a basic conceptual level, though, unless you're making a massive jump across both scale and design philosophy, you very likely will be able to catch on fairly quickly.

For instance: When students are learning a new real-world language, it may take a considerable amount of time. Once they have, however, learning another is substantially easier. Learning how to develop is figuring out what to do as much as how to do it. Once you have down the basic idea of "this is what I need to do, this is how I would do it normally, I just have to find the counterparts on this platform," you should have it figured out.

18. Have you ever proposed a project, then seen it through to completion?

After a certain point with most organizations, managers tend to start asking "What ideas do you have to improve what we do here?" You'll usually have a pretty good understanding of how things work and why they work a certain way, but not enough time under your belt to just write it off as "that's the way things have always been." This can be a tremendous asset to organizations, as fresh eyes can mean great changes so long as the person has patience and access to the resources to get it done.

19. Why do you code?

This is a bit of a strange question, I know, but is it one you can easily answer? "Because I'm good at it." "Because it pays the bills." "Because I want to make sure that Skynet likes me." "Because I like being challenged." Whatever the answer is for you, be sure to not only have the answer ready but understand why that's your answer.

20. What do you want to learn in the next 12 months?

Maybe you've always wanted to get into Big Data? Perhaps understand more about database servers or graphic design? Or maybe just stay right where you are but be better-prepared whenever the next version of your primary language comes out. This can literally be anything you want, and who knows — they may be able to assist you with that.

Level 3: Cleanup on Aisle 5!

21. Have you ever had to deal with the cleanup after someone pushed a bad update to production?

Sadly, this will happen. Sorry. Whether or not it's something that you did or something that a coworker did, or a third-party vendor changing something vital in the middle of the work day (looking at you, API vendor who shall remain unnamed), it will happen. How you deal with it, and more importantly what you're in a position to be able to do, is critical. Sometimes preparation will mean having a workaround standing by, while other times it will mean just making sure that your source control is used properly, and backups are taken regularly.

22. If you had a specific section of code continuously causing problems, what kinds of utilities would you use for troubleshooting?

Log files have been and will always be your friend when it comes to troubleshooting. Granted, the amount of information you actually receive from them can sometimes make you want to pull your hair out, but they are always a great place to start.

When it comes to actual IDEs, on the other hand? While I've been trying to stay vendor-neutral in this, since the utility itself can be used for many potential languages, I'm going to give a shout-out to Microsoft's Visual Studio as it can be a massive assistance in troubleshooting where problems lie. Whether it's basic features like setting up breakpoints and commenting out code, to auto-complete pointing out misspellings to showing you what's not going to perform properly during compilation — this type of tool and others like it can be of enormous help.

23. How would you handle performance optimization?

Throwing bandwidth at a problem only helps so much. Sooner or later, you're going to have to start cleaning house on how your project manages the data it serves up. Sometimes it's as simple as cleaning a SQL query, while other times it's removing junk data from the database or reducing the resolution of images being hosted.

After a while, though, the solutions may start to get a bit more expensive if you have to use advanced methods such as load-balancing. Deciding which solution can get you the most bang for your buck is critical to proper optimization, so be sure to look at all your potential options before getting quotes for new hardware or services.

24. What developers inspire you?

If you've ever listened to a really good TED talk, watched Greg Street and Chris Metzen handle a room full of gamers ready to pounce (and see what happens when they aren't around like this year) or just had Steve Ballmer on loop for eight hours, you've seen the power that certain people have that create things that we not only enjoy on a regular basis, but can motivate us to do better ourselves.

25. What kinds of personal projects are you currently working on?

Years and years ago, I was the guy with the big DVD library that everybody wanted to borrow something from. I didn't really think much of it at the time, until a move or two later and a lot of discs came up missing. After this, I decided it was time to organize! I had started to work on a custom solution, but it turns out that there are a huge amount of people out there that had the same idea and created incredible utilities for tracking these types of items that I was able to repurpose.

Regardless of whatever it is, everybody has a pet project on a back burner that they turn to when time allows. These are the kinds of projects that allow us to push our abilities, while at the same time get a practical application out of it.

26. What are your feelings on Java and/or Flash?

Okay, yes, time for the elephant in the room. Yes, both were incredibly powerful and influential down to this day. Between the two of them, however, they are responsible for serious effects on the Web as a whole and are just not capable of holding pride-of-place as they once did. So if it comes down to having the option of using these over using something else? Don't. Just don't.

27. What's the worst project you've ever had to work on?

Everybody has that one horror story, that one super-annoying project that no matter what you tried or were able to accomplish just didn't work out properly. Whether this is because somebody else wasn't able to complete their portion on time, the project parameters changed fifty times or the objective literally could not be done, everybody has that one that just still upsets them to this day. Just don't let it get you aggravated in the middle of the interview. That could be problematic.

28. How do you manage existing completed projects when variables outside your control force major changes?

Depending on third parties to provide services always comes with positives and negatives. On the one hand, you can usually rely on these elements to be consistently available, regularly updated and most of the time, work just as well as locally-housed code. But all it takes is one out-of-band change, one tweak on their side that breaks everything to have a load of calls at the help desk and people panicking at 3 AM.

The best part about this? By the time you start digging into the code, trying to figure out what in the world is going on, half the time it "fixes itself." This of course can be somewhat resolved by having versions of some things like jQuery hosted locally, but for other items like third-party APIs, the backup might have to be finding another vendor “just in case.”

29. Have you ever been a team lead on a major project?

Working on assigned projects is one thing and working on projects that you've suggested is another, but leading a project that require a full team is a whole different package. Depending on people to do their jobs can be one of the most stressful parts of seeing a project through, and you may still end up having to do that portion yourself based on timelines. But seeing a completed project that your people put together? There's nothing like it.

30. Have you ever worked on consolidating two different existing applications together?

Redundancy can be a good thing, especially when it comes to projects that need to be highly available. However when there are multiple elements pulling the same information to do the same job with only marginal differences? It's time to consolidate. Sure this requires considerable knowledge of what the applications do and what they talk to, but if it means a streamlining and reducing overall expenses? Sure — it's usually worth the hassle.

Conclusion

Web development still is, and for the foreseeable future will continue to remain, a fast-moving field. Organizations regularly try to grab the best people they can, with the skills that will push their offerings to the next level. During an interview, this is your chance to show that not only can you meet what they're looking for — you can surpass their expectations. Performing research on the organization you're applying for can give you an edge on the kinds of specifics they'll be watching for, making it that much more likely to get your foot in the door.

However, no one can know everything. We've tried, and have a dedicated ibuprofen bottle in the desk drawer to show for it. This means that if you need a refresher on what an organization is looking for, you'll need resources. You might want to check out Skillset.com, which has over a hundred thousand questions and answers covering a huge range of topics. Map out the information you know, dive into those fields and refresh your knowledge for the job you're looking for.

FREE role-guided training plans

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Interviewing isn't easy. It takes work to prepare for one and can be quite challenging depending on who you're speaking with. But with a calm presence and plenty of preparation before time — you'll knock it out of the park.

Kurt Ellzey
Kurt Ellzey

Kurt Ellzey has worked in IT for the past 12 years, with a specialization in Information Security. During that time, he has covered a broad swath of IT tasks from system administration to application development and beyond. He has contributed to a book published in 2013 entitled "Security 3.0" which is currently available on Amazon and other retailers.