I'd be worried about both! If you have to clear a float, you can do it even more cleanly in CSS by using a psuedo element.
The old trick was to set `overflow: hidden` on the element containing floated items so it would always expand to contain it - but then things like box-shadows get cut off by the containing element. To get around this, you can use an `:after` pseudo-element on the element that contains the float items. This comes after the last floated item and automatically clear the float without needing `overflow: hidden`.
The advantage of clearing a float this way over sticking `<div style=clear:both></div>` or a `.clearfix` class in your HTML is that when doing responsive design, my method keeps the clear in your CSS (and possibly only one @media query). With a `<div>` or class in your HTML you have to deal with that element at all widths - now do you have to specifically override your `.clearfix` class inside a @media query when doing responsive styles? How intuitive is that?
Imho, clearfix as a solution to a problem that existed before CSS3, when people used the `float` role to align things in a row -- when time came to stop the alignment behavior, you applied a clearfix. Today, you really only float things that have a block flow inside an inline context, like asides, pictures, blockquotes, etc. You don't really need clearfix since your inline content should just flow around it. If you are using floats on entire sections you are obviously doing something wrong, and you ought to ask your self if `display: flex` on the parent wouldn't be a better fit.
If I interviewed anything but a junior candidate and they said this I'd immediately dismiss them. Sure, flexbox can solve most of the problems, but flexbox isn't always an option. Any candidate worth their grain of salt would know this regardless of whether or not they knew exactly how clearfixes work. I'd much rather them tell me they knew the purpose, but didn't exactly know how they worked than immediately dismiss it.
When isn't it? If you're developing for old (now unsupported) versions of Internet Explorer I'm not sure they'd be bothered about being turned down (unless they knew about that when applying). Just because something was done some way once doesn't make it right, and putting emphasis on 'clearing float' questions would show your company use old, bad practices.
I wouldn't dismiss a candidate for not knowing how a clearfix works. What's important is they understand positioning and layout and how things tend to fit together. I'd reasonably be able to extract this information from them. Asking about clearfixes is one of many ways I'd go about picking their brain.
What I would dismiss them for, however, is the cocky attitude that they never need to bother learning any "old, bad practices." I'd dismiss them for thinking they are "above" working for a company that supports technology that was released just 4 years ago. Further, I'd dismiss them for the attitude that their solution solves all the problems without considering potential drawbacks. These are all huge red flags that show they may technically be knowledgable, but are very difficult to work with. Not someone I want on my team.
"...is the cocky attitude that they never need to bother learning any "old, bad practices." - so before learning ES6 everyone should learn how to use inline onclick events, alerting to debug etc otherwise they're "cocky"?
"..technology that was released just 4 years ago" - if you haven't been keeping up with the news on IE10 then... yeah
"I'd dismiss them for the attitude that their solution solves all the problems without considering potential drawbacks." - no one said there weren't any drawbacks, just when compared with old bad-practice hacks.
"but are very difficult to work with. Not someone I want on my team." - it sounds like the kind of people who're using react would be sad about that.
This post is evidently about junior developers, just because something is old/established doesn't make it right or that it shouldn't be questioned, because there's usually a better way.
Last time i checked, IE9+ are still supported browsers. Of which, IE9 has no support for Flexbox and IE10+, only have partial support.
(Not counting Edge on those stats as it is after all an entirely new browser).
"At the end of 2015, the combined market share for IE8 (8.95 percent), IE9 (6.67 percent), and IE10 (4.18 percent) was 19.80 percent,"
Sure, use flexbox exclusively if you want to push away nearly 20% of visitors. Also notice how the older of those browsers has the highest single percentage of use, and reflect on what that might mean about how likely those users are to upgrade.
I prefer the more customer-centric method of looking at what browsers my customers use and supporting them, rather than the more developer-centric view of "X is hard, I don't want to do X anymore and it's no longer supported anyway so there!".
By all means keep an eye on the browser usage for your audience and drop active support for older browsers once they fall below a certain percent, but don't take another company's actions as a license to screw over your (hopefully paying) customers.
The old trick was to set `overflow: hidden` on the element containing floated items so it would always expand to contain it - but then things like box-shadows get cut off by the containing element. To get around this, you can use an `:after` pseudo-element on the element that contains the float items. This comes after the last floated item and automatically clear the float without needing `overflow: hidden`.
Imagine markup like this:
The advantage of clearing a float this way over sticking `<div style=clear:both></div>` or a `.clearfix` class in your HTML is that when doing responsive design, my method keeps the clear in your CSS (and possibly only one @media query). With a `<div>` or class in your HTML you have to deal with that element at all widths - now do you have to specifically override your `.clearfix` class inside a @media query when doing responsive styles? How intuitive is that?