How do you declare a custom font and apply it to headings?
This tests @font-face usage for custom web fonts. A good answer declares a font-family name and src URL inside @font-face, then applies that family to heading selectors.
What's really being asked
This question checks whether you understand the two-step process for using custom fonts on the web: first declaring a font resource with the @font-face at-rule, then referencing that declared name in a font-family property on the elements you want to style. It also reveals if you know the difference between a font file path and a font family identifier, and whether you consider fallbacks, formats, and basic loading behavior.
The full answer
First, the candidate should describe an @font-face block containing at minimum a font-family descriptor to define a custom name and a src descriptor pointing to the WOFF2 file. Second, they should mention that src can include a local fallback using local() and a format hint such as format('woff2') to help the browser decide whether to download the file. Third, they should explain applying the font by using a selector targeting headings, for example h1 through h6, and setting font-family to the custom name declared in @font-face. Fourth, a strong candidate might mention adding a generic fallback like sans-serif or serif to the font-family stack for resilience, and possibly setting a font-display strategy to control loading behavior.
The mistakes people make
The biggest red flag is trying to put the raw filename directly into a font-family property without using @font-face at all. Another mistake is omitting the src descriptor inside @font-face, which makes the rule invalid. Some candidates forget that @font-face only declares the font; it does not apply it to any elements automatically. Confusing the font file URL with the font-family name is also a signal of weak CSS fundamentals. Finally, failing to provide a generic fallback family can indicate inexperience with resilient design.
What usually comes next
An interviewer might ask how you would handle font loading performance, which opens discussion of the font-display descriptor such as swap, optional, or block. They might ask about supporting multiple font formats for older browsers, which involves listing multiple sources in src with appropriate format hints in order of preference. Another follow-up could be about subsetting the font with unicode-range to download only needed glyphs, or about variable fonts and how they change the @font-face declaration by allowing a range of weights or styles in a single file.
A concrete example
Suppose you have a file named headings.woff2. You would write @font-face { font-family: 'CustomHeading'; src: url('headings.woff2') format('woff2'); font-display: swap; } and then apply it with h1, h2, h3, h4, h5, h6 { font-family: 'CustomHeading', serif; }. This separates the resource declaration from the typographic styling, provides a fallback while avoiding invisible text during load, and uses a format hint so the browser can skip the download if it does not support WOFF2.
Interview question
Which approach correctly uses a custom WOFF2 font file to style all headings?
- a.Create an @font-face rule with only a font-family descriptor, then reference that name in the heading font-family stack
- b.Define @font-face with a custom font-family name and a src descriptor, then apply that custom name via font-family on heading selectorsCorrect
- c.Set font-family: 'headings.woff2' on the h1-h6 selectors so the browser downloads and uses the file directly
- d.Declare @font-face with a src URL, which immediately applies the font to every heading without any extra rules
Why? this is the answer
Custom fonts require a two-step process: an @font-face rule declares the font with a family name and src URL, and a separate selector applies that family name to elements. Option C confuses the file path with the family name, Option D wrongly assumes @font-face auto-applies, and Option A omits the src descriptor which makes the rule invalid.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on css — each one lists the topics its interview covers.
See open roles