80 front-end job applications – nearly no one had basic HTML/CSS/A11y skills
wdrl.info
wdrl.info
Asking a pop quiz of arbitrary tools / techniques that you happen to have remember really isn't a good way to evaluate if someone is a good developer. I am a good developer and I only just remember what clearfix is, I most certainly couldnt explain how it works.
My instant reaction was, "You keep using that word, I do not think it means, what you think it means."
"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".
If this post were phrased as "web developers don't know accessibility" it would be obviously true and uncontroversial. Unfortunately.
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).
JavaScript to the rescue!
FTFY
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;
}
Why? I haven't needed to use floats at all since moving to flexbox.
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.
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.
"..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.
Hence the "anything but a junior candidate" from my original post.
"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.
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).
> 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.
>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.
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.
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'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.
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.
While every developer has things that they really like and appreciate, projecting this focus onto others and focusing on this one fetish point to the exclusion of everything else is detrimental to a project. Your job should be to build a team of smart developers who bring complementary skills to a project and who can learn things that are important to the project, not to build a clone army of yourself.
If the author was a comic book store owner interviewing prospective workers, the equivalent to this would be him rejecting hundreds of job applicants because they didn't know the thematic development and character interaction in issue #431 of Gunsmith Cats or some other random obscure anime or whatever.
Although I only had the chance to review their personal websites or github profiles
Many are not able to choose the right HTML elements, to explain why and how a clearfix works, or what ARIA roles are for, but they can use React and Angular.
You want to talk about incompetence, and your "application review" consists of browsing the web.
It seems that his gripe is more with people being unfamiliar with certain accessibility tools that he likes.
That doesn't grab headlines like claiming nobody knows basic html and css so though, so he threw that in front.
"People living in glass houses, ...."
It's almost like we've spent decades layering abstractions on this stuff so we don't have to wrangle it ourselves, isn't it.
Starting with some specific framework or tool set inevitably limits what you can achieve. Surely the recent emphasis on frameworks over fundamentals has been a major contributor to the Web full of bland, practically identical sites that we see today.
I want to use abstractions and tools where they offer an additional benefit, but without being limited to whatever some predetermined choice of tools or abstractions can do.
It used to be mostly plaintext and basic colors with no responsiveness, under construction gifs, basic images, and flashing text. Before that, just text. We're still learning as an industry. Web technology has not (and may never) settled like the hardware in your toolbox.
Those frameworks are geared for productivity, not possibility. Productivity is where the money is.
As for productivity vs. possibility, I certainly don't dispute that productivity is one place where the money is[1]. However, that doesn't mean there isn't also room for innovation, and it certainly doesn't mean there's no money in doing things better than what you can achieve with Bootstrap, Angular, and a couple of junior developers who don't know much else. In an increasingly monotone and commoditised technology field, more interesting and/or effective presentation can certainly be a USP.
[1] I might question how sustainable that productivity proves to be over the longer term with many framework-heavy projects, but that's a separate issue and probably not worth getting distracted here.
So, what you really want to do is just build some apps, not learn CSS. See the difference?
However, we were talking about knowing HTML and CSS vs. knowing abstractions built on top of them. In that context I didn't interpret the post I replied to the same way that you did.
WebGL, WebAssembly, emscripten
Because there's not a well known standard of what solid markup skills are. It's not really a surprise that people come to you without knowledge you claim as necessary when they had no idea it was necessary.
The same is basically true for any position in any area of software.
HTML 5 added the semantic tags, which are great, but there is less clear decisions for deciding section/article/div that the prior selection of just using div. There are other cases where it has introduced more confusion into the process where the semantics aren't straightforward to determine.
And progressive-enhancement is pretty much forgotten anymore. All the Javascript frameworks and pushing to work on the cutting edge of what's available, have forced a huge portion of effort to be spent on graceful-degradation instead. And working at the edge means that everyone is already working off any adopted standard, and just shimming everything to do what they want.
The front-end development out there is just kind of dumb at the moment in those regards.
As a developer I have grown a tough skin to managers that keep complaining that "these JS/Python kids today don't know anything about register allocation and data segments in assembly!"
Workers unable to fully understand your technology stack is an universal problem, goes far beyond computers and web. There are only 2 options for you to deal with it:
1. The Silicon Valley approach: pay top dollars to whoever knows the technology you want.
2. The German Mittelstand approach: nurture, train and develop your own experts. Make deals with technical schools, offer a viable career path to young students and help them learn.
Alternatively it seems like a good case for putting some sort of earlier filtering mechanism, like giving a short quiz or coding exercise to see if they know what you want them to know. I remember reading an article by TripleByte on how their quiz actually was a better filtering mechanism than a coding exercise though.
> After reviewing a lot of applications in the past days, I can only agree with Kristian Glass here and say: “If you get the chance, always send a cover letter”. It’s your opportunity to say something about yourself and make clear why you apply for the job.
I can understand why employers feel this way, but from an applicant's perspective, the reason someone applies to your company most likely is that they need to make a living. Frankly I don't think there's anything wrong with that and it's not something I would think stops people from being good employees. After all, it's difficult to know how much you'd like to work somewhere unless you've actually been there.
This has been discussed many times, both here on Hacker News as well as elsewhere. To recap that argument, HTML started life with 2 competing and conflicting goals. One goal was to become a GUI for TCP/IP packets. The other was to provide structured information, as SGML had done for publishing.
The conflict was obvious by the late 90s, and then for awhile the good folks at W3 thought that XML would provide the answer. And XML did work at providing structured data, much as SGML had for printing (though the criticism arose that attributes should have been left out of XML, as they were only useful for printing). But when XML was stretched to again try to be a GUI for TCP/IP, the system broke.
Somewhere around 2006, Sam Ruby (W3C working group co-chair) shared a wonderful anecdote on his blog that revealed how broken XHTML was. He said that he had sent his daughter an SVG image, and she wanted to share it with her friends on MySpace. But she couldn't. Because MySpace was not XHTML compliant, and SVG could only render on XHTML compliant pages. And yet if he had sent her a gif or a jpeg, she would have been able to share it. Draconian error checking might be great for an information exchange system such as XML, but it did not work for a GUI that had to be somewhat informal.
In 2004 Mark Pilgrim wrote the great piece "XML on the Web Has Failed":
http://www.xml.com/pub/a/2004/07/21/dive.html
Now it is 2016. We are looking back at 25 years of failed experience. We can clearly see that HTML and XML both failed, completely, as GUIs for TCP/IP packets.
So developers are being rational. They are "voting with their feet" (actually their minds). They don't learn HTML because they know HTML has failed.
What is the best way to create a GUI for TCP/IP packets? I don't know, but nearly all developers agree that Javascript is a better way to get there than HTML.
There might be something even better than Javascript, and we should all keep experimenting and learning and trying new things.
But HTML has failed, and it is good that developers recognize that.
If you think HTML can be used to send structured information, I would urge to read the essay that Mark Pilgrim wrote in 2004. I posted the link before.
Also, please consider all the many arguments that Sam Ruby has made against HTML-as-structured-data. From 2005 forward, there were many people who wanted HTML5 to be an extension of XHTML, but as Sam Ruby kept asking "Why should we call something XML if it is clearly not XML?" Over the years, in his role as co-Chair of the W3C working group, he kept making the point that "draconian error checking" is part of the XML spec, and it can not be reconciled to people's actual use of the Web. That is why HTML5 relaxed all the rules regarding validation and structure.
This is Sam Ruby in 2009:
"So, while I doubt that I will ever understand why there are people who insist on calling their pages they produce with the intention of being processed as HTML by the name “XHTML”, I can’t deny that there clearly is something that such people want. (By way of comparison, I am quite happy to say that this page is served as XHTML to browsers that support such, and as HTML to browsers that don’t). From my experience, this is tricky stuff, and not something that should be recommended lightly.)"
Hiring people, don't confuse route memorization with job performance. It's an absolute ridiculous requirement.
Thankfully not one of those applicaments would have wanted to work there.
It sounds like these applicants wasted their time to help the Author write some bait click article to attract traffic.
<button role="button">Sign in</button>
<h1 role="heading">Heading</h1>
But it's good to validate the markup regardless, to be sure.
https://en.m.wikipedia.org/wiki/National_Federation_of_the_B....
Even an easy JavaScript programming tasks can filter a lot of applications so you can concentrate on best candidates.
That way you can pick the best ones by technical merit, not be their ability to write nice resume.
I don't remember the exact price, but when my company used them it was something in range of $100-500 / month.
That's like you alienate people
This is so ironic. This working developer, not born with a silver spoon in his mouth, rightly suggests that there's too much economic inequality, too great a gap between the wealthiest and poorest people. Many influential people have expressed the same sentiment -- as just one example, in a NY Times op-ed piece, billionaire Warren Buffett said, "My friends and I have been coddled long enough by a billionaire-friendly Congress. It’s time for our government to get serious about shared sacrifice."
http://www.nytimes.com/2011/08/15/opinion/stop-coddling-the-...
Some inequality is inevitable, indeed it can be argued that some economic inequality inspires people to try harder to raise themselves up. But when the middle class disappears, when those below the glass ceiling realize they're permanently trapped, this can be dangerous for all of us.
The irony is that the very poor and the very rich both see the problem, the danger, caused by extreme inequality, but congress refuses to see it.
To pinpoint one of his major gripes - I've moved further "back" down the stack since, but when I was doing strictly front-end I had to make a fully accessible page for some clients, but not others. If anything this post gets me aware that portfolio content is also judged for accessibility, so it provided me that benefit should I take on front-end projects in the future. Some may call it lazy, but I tend to focus on "bigger picture" accessibility issues such as contrast and font scaling.
Also with clearfix - many times its actually abused and painted on every element including ones that don't need to clear its children. It's also not the only way to solve the problem - soon display: flow-root will be adopted across browsers.
I'd say you're looking for a very specific skill set and you'd have better luck teaching a capable candidate how you want your toast buttered than expecting one to walk in with your ideal breakfast.
I love this site as a crutch for most of these kind of specific things: http://learnlayout.com/
It finally got me to understand where I was screwing up my understanding of things.
Kinda like i18n for "internationalization."
< 162
162 results, but I'm going with "aboriginality" skills.
Most of the times you get a bloody design and you have to fit it in all screens, even in a bloody watch (2 years ago I was asked to support the symbian browser!). You get asked to make the features and functionality to work everywhere. And also you have to deliver that yesterday.
JavaScript is a beast though. But if you use only the good parts and stay away from the quirks, someone should be able to code JavaScript within a few days.
What you should look for instead: Do they like learning new stuff? Are they humble and prestige-less? Are they intelligent and can think in abstract?
> Many are not able [..] to explain why and how a clearfix works, or what ARIA roles are for
I don't understand what the author expected to learn by browsing someone's hobby projects/personal homepages, without seemingly engaging in a discussion with the person who wrote the code.
You reap what you sow...