It doesn't even sound like he interviewed the candidates at all.

> Although I only had the chance to review their personal websites or github profiles and this might of course not be a full show-off of their knowledge, it assured my lately developed opinion on web developers.

Apparently because people's personal projects weren't developed with accessibility in mind he concluded that developers don't know HTML/CSS.

>I only had the chance to review their personal websites or github profiles

>Many are not able to [...] to explain why and how a clearfix works, or what ARIA roles are for

I have only had the chance to review this blog post but this person doesn't seem to be able to explain simple arithmetic, describe the difference between something that is round vs square, or tell me what a spoon is used for.

Personal projects are a bit questionable as a skill test.

I've been planning to do a personal site for a long time and wishing i could contribute on github more but most of the time the only contribution on github ends up to be bug fixes to libraries I use at work and I still haven't gotten anywhere with my personal website.

Most of my best code will never be seen by any interviewer since it's done at work.

Now if any of my personal code was making me money that would be different but I have nothing like that at the moment.

Agreed. And on top of that, any personal projects I do actually find time to work on are typically pretty rushed (due to the lack of time) and are not going to be the best examples of my work product.

Typically I am just trying to write something quick and dirty to accomplish some task and want to share it in case somebody else might benefit. I'd love to make time to go back and polish things, but rarely do I have the time.

I know great, not just good but GREAT developers who don't even have a GitHub. Yes, it's awesome when someone has one, but if someone doesn't have something on their blog or GitHub does that mean they don't know said subject? Nope. I'm questioning the methods used here.

Agreed. I understand missing accessibility (either you have ARIA or you don't), but what does "solid markup skills" mean? The differences between many tags is just user agent stylesheet defaults. If I wanted to be extra crazy, I could build a website using <div> alone. Or maybe I am just a bad developer.

It matters for accessibility. Marking up headers as headers, lists as lists, etc. is valuable for people using assistive technology like screen readers.

If this post were phrased as "web developers don't know accessibility" it would be obviously true and uncontroversial. Unfortunately.

> I could build a website using <div> alone.

Then my scraper that reads headlines on your website with `//(h1|h2|h3)` will not work. And I will not be able to read and linearize your tabular data. And plenty of other things. (Things you probably do not care about.)

Oh, and you website will have no links (the `href` attribute of `<a>` is not simulable via CSS).

The thing is, most developers aren't targeting your scraper. At most they're targeting Google's, which can handle all sorts of whacky and not very semantic markup - and glean a decent amount of semantic structure from it.

You can do some hacky stuff with onClick listeners for links, especially if its a single page. That said, I do not do this. But I don't think I use much beyond div, span, a, ul, li, table (and friends), form (and crew), h1-6, script, body, head, and html. I know there are more HTML tags, but I rarely use them. They are all pretty self explanatory, and I have hard time believing the author looked at 80 pages and everyone used the wrong tags.

> Oh, and you website will have no links (the `href` attribute of `<a>` is not simulable via CSS).

JavaScript to the rescue!

/s

FTFY

Totally agree. I see front end job descriptions asking for understanding of Java and .Net but no mentioning of JS, CSS or any HTML. There could be easily a miscommunication of misunderstanding what the company want. Not saying the job description used here is wrong, just an example of miscommunication.

I recently saw an Ad for a front end job requiring: "strong Java Scripts" skills.

Just got an email yesterday from a corporate recruiter with the line "must have strong JAVA script" skills.

My instant reaction was, "You keep using that word, I do not think it means, what you think it means."

10 points for who can name the movie that has the quote...

"Well, you told me I have a plethora. And I just would like to know if you know what a plethora is. I would not like to think that a person would tell someone he has a plethora, and then find out that that person has no idea what it means to have a plethora".

I think that would be down to the recruitment agencies most of the time. Truth is they have a phone call and assume it's 2 separate words.

In my experience job postings like that focus solely on JavaScript and whatever tools the company uses—HTML/CSS is usually implied, no one has ever asked me about it.

If "Hire for how they learn, not what they know" was followed, I'm sure there would be a better success rate than 0%.

Agreed on the memorization of trivia questions.

I've encountered this clearfix problem and solved it independently perhaps five times over the last decade, but just had to look it up since I had no idea it was called "clearfix" ... someone's marketing term for it.

Not really a "marketing" term so much as one that became popular during the "everyone must write their own grid framework" era.

Yes, I was being facetious.

I'd be worried they were asking about clearfix as opposed to flexbox.

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`.

Imagine markup like this:

    <main>
      <section></section>
      <section></section>
    </main>
    
    .section {
      float: left;
    }
    
    main:after {
      content: '';
      display: block;
      clear: both;
    }

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?

This right here is why I hate CSS.

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.

"I'd be worried about both! If you have to clear a float..."

Why? I haven't needed to use floats at all since moving to flexbox.

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.

lojack: "...but flexbox isn't always an option."

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.

> This post is evidently about junior developers

Hence the "anything but a junior candidate" from my original post.

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).

Guess that was before January 2016 then? http://venturebeat.com/2016/01/12/microsoft-ends-support-for.... It is finally time to only support ie11 and beyond! So flexbox away and be happy

From the article you linked to:

"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.

That's % of desktop users (desktop use itself is declining rapidly - I don't know anyone non-tech who uses a PC/Laptop and most devs should be mobile/tablet-first now). Also that was before the big "please upgrade" message Microsoft send out to everyone using IE8/9/10.

If it was purely about numbers, I'd attempt to support to Opera Mini and it's 300 million users. But I don't, and I've never met anyone who does, yet some people bring up IE10 support on a React-driven, Mobile-first web app to appease managers who have always wanted support for older versions of IE "just because". Unless the clients are government/big bank I can't really see any justification for supporting them (and no one supports IE8 - even though it has double the usage IE10 has).

Or, at a higher level, maybe their approach to soliciting candidates is wrong. A lot of the job descriptions I see are sloppy. Or they're so vague that you can't figure out what you'd actually be doing (or what the day-to-day would be like). Some of them throw in peripheral technologies just to cover all the bases or something.

It seems like a lot of hiring managers/companies treat a job description as an afterthought when it actually has a huge effect on who applies for a position (_obviously_). People who have more options will tend to ignore the sloppy, vague postings.

The person who wrote this article seems more conscientious than this, but it's something to consider.