Cracking the Frontend Interview — A blog series on my preparation for frontend interview, this series acts like my notes and summary on what's really important to tackle the job.
But I dare you to say bad about HTML or make it optional to learn in public, you’ll get snarled by experienced developers who might barely write a single raw HTML tag in years. They will blame you for not adopting semantic markup and accessibility almost all the time. So certainly it will hurt you in a frontend interview.
This post is not a how-to on writing HTML or an exhausted list of HTML Q&A for interviews. I’m sure there are tons of HTML references and style guides out there for you to learn HTML in depth. This post only covers some very important topics related to HTML in a sense of what they are and why on earth we need to learn them.
The current HTML Living Standard is developed by WHATWG, which is made up of the major browser vendors (Apple, Google, Mozilla, and Microsoft). HTML5 is the fifth and current major version of HTML, and has following building blocks:
What is semantic markup? It’s simply to use the right elements for the right purposes. HTML5 defined tons of semantics elements for you, your job is to use as many of those as possible instead of polluting your site with
Who benefits most from this movement? The robots! Yes you can create a beautiful website without caring about semantics at all. Those semantic elements were created to help automated tools like search engines, web crawlers, screen readers reading your sites easier.
Semantic markup also makes your life easier with readability when reading the source code, debugging html, engaging new projects or crawling the web. No more creative unconventional class names like
<div class="awesome_nav"> or
<div class="leave_me_alone"> (
nav to play the hero).
I developed many web crawlers (personal use only) years ago and I really hated sites with unpredictable HTML class naming conventions, dynamic HTML tags or confusing site structures. Thanks to semantic markup, the life of crawler developer is getting better than ever 😅.
I’m talking about metadata on the
<head> of HTML document, this is an awesome place to put tons of useful things which will be easily consumed by automated tools. They are not visible to end users but can be inspected by browser developer tools.
Meta tags for web browsers: These are basic tags for browsers to know more about your site and render properly.
Meta tags for search engines: Search engine like Google is really smart and powerful, besides server-side rendering pages they claim they can crawl client-side rendering ones. It’s often to use following tags to feed search engines some important info.
Meta tags for social sharing: It’s quite easy and straightforward to have beautiful sharing cards on Facebook, Twitter, LinkedIn, Pinterest. Most of them support Open Graph protocol. Use following tools to test social sharing: Facebook Sharing Debugger, Twitter Card Validator or metatags.io.
<head> <!--Facebook / Open Graph --> <meta property="og:type" content="website" /> <meta property="og:url" content="https://hoangbkit.com/" /> <meta property="og:title" content="Hoang Nguyen" /> <meta property="og:description" content="Software Engineer" /> <meta property="og:image" content="https://hoangbkit.com/img/avatar.jpeg" /> <meta property="og:site_name" content="hoangbkit" /> <!--Twitter (also supports Open Graph)--> <meta name="twitter:card" content="summary_large_image" /> <meta name="twitter:image:alt" content="Avatar" /> <meta name="twitter:site" content="@hoangbkit" /> </head>
And don’t forget that you can put literally any custom metadata in the
<head> for any purposes like analytics, prompt to install apps on mobile browsers, site verifications, tracking, you name it.
Most of frontend developers don’t use microdata which is a part in HTML standard that encourage webmasters adding more indicators on what content is all about.
You only want to do this when you want your site to be understood even more by search engines besides sematic markup and metadata on
<div itemscope itemtype="http://schema.org/Event"> <div itemprop="name">Spinal Tap</div> <span itemprop="description" >One of the loudest bands ever reunites for an unforgettable two-day show.</span > Event date: <time itemprop="startDate" datetime="2011-05-08T19:30">May 8, 7:30pm</time> </div>
Search result pages are getting more complicated with carousels, context based, mobile, rich snippets, sponsored results, direct plain text answers, etc. To maximize the chance of your site displayed in these results, you have to feed search engines even more!
Web accessibility is a practice encouraged by HTML standard to help people with disabilities consume the web. It’s an important movement on an effort of providing equal opportunity for everyone in this world.
This is made possible by authoring tools, web content, user agents, assistive technologies and especially you - frontend developers. The Web Content Accessibility Guidelines is long and complicated, I bet not many of you read that but I’m sure you already do a good job if you’re already following semantic markup.
Accessibility is underrated not just by newbie developers but also experienced ones. The main reason is we don’t see the direct benefits or immediate impact if we do follow it. Why? Simply because most of us are perfectly physically normal.
It’s okay to ignore accessibility when you’re developing almost-no-one-use websites, but should take great care of it when developing popular ones. Making this as a habit from the start is even more awesome, many people around the world will be very delighted with what you’re doing.
English only website is fine for individuals and small companies, but i18n is actually a huge deal when you’re developing sites for popular international brands. Knowing this is important when you’re applying for big enterprises.
I18n ensures supports in different character sets, writing directions, different approaches to format and store data, cultural problems and most importantly the design needs to be flexible enough to accommodate local needs.
Google announced an open source HTML framework called AMP (Accelerated Mobile Pages) for better and faster experiences on the mobile web (Google said that) in 2015. This was created in an effort to play against Facebook Instant Articles.
AMP can be used in websites, stories, ads and emails with three main restricted building blocks: You must use AMP custom HTML components
The main benefit of using AMP is to make your site appear on Google Top Story Carousel, it’s a powerful way to boost mobile SEO and CTR of news content.
This AMP is very controversial over the years, people blame it for going against the open web and for Google’s own sake. You should think twice when adopting it and with your own risk because you’re moving to the parallel world which has very unpleasant developer experiences.
We use HTML emails everyday but we normally don’t write it, it is often already integrated by email clients or email marketing services. It’s good know how to write raw HTML emails because it might be useful in some startups when you’re going to develop transactional email templates.
To support wide variety of -not-so-innovative email clients, you can only use a very small set of HTML+CSS with a lot of limitations compares to web HTML.
It’s safe to use static table-based layouts, simple inline CSS, HTML tables and nested tables, web safe fonts. Cautious use with background images, custom fonts and embedded CSS.
I ignored many basic topics in this post, explore more on your own to have an solid exhausted knowledge about HTML. I recommend following resources to dive deeper on the quest for frontend job: