At 80 people it might start being the time to question whether its really everyone else thats unskilled or your approach to evaluation is wrong.
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.
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.
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.
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.
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".
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.
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.
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.
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).
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.
Every developer has a specific set of tools/technologies/techniques/focuses that they really like and appreciate and that gives them a technical boner. For this guy it's HTML markup and accessibility stuff. For me it might be something like frontend performance and minimal design. For another dude it might be writing abstract and clever code that's as short as conceivably possible. For another guy it might be writing the most readable and documented code possible that eschews all cleverness. Another guy might be focused on writing 100% tests. Etc.
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.
If the skills you're looking for are that basic, why wouldn't you just hire one of those 80 applicants and spend an hour teaching them what aria attributes are?
One has to wonder how much time was spent dismissing applicants, and if that time would be better spent showing the new hire his personal preferences (which are only preferences, there wouldn't be 100+ comments on this thread if it was standard)
Although I only had the chance to review their personal websites or github profiles
and then
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.
No kidding. They couldn't explain clearfix because you never asked them any questions.
You want to talk about incompetence, and your "application review" consists of browsing the web.
This guy's gold! Someone can learn react and angular but he thinks they're incapable of learning some accessibility attributes? I wonder how competent he is with angular/react...
Funny that he's criticizing applicants for the perceived lack of knowledge of web accessibility and the neglect of aria usage and yet in the same post, not a single reference to either « aria-labelledby » or « aria-describedby » could be found in the markup.
I respectfully disagree. I'd much prefer to understand the real technologies that run the web -- HTML, CSS, HTTP, and so on -- and then use tools and build abstractions on top when it's useful.
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.
>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.
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.
I think you overlooked about a decade where we'd moved well beyond slightly annotated text but hadn't yet entered the era of framework dominance. The Web was a smaller place then, but IMHO a much more interesting one in terms of trying out different designs and interaction styles.
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.
I find bland, practically identical sites to be the most useful sites. The design gets out of the way and puts the important thing - the content - front and center.
I remember someone on here scoffing at Googles main page on an article on design. It seemed to have bypassed him that it was designed for usability not shiny-shiny design.
A lot of these objections to abstraction sound like the objections to abstraction that we had back when we first invented interpreters and compilers. Are you sure that you want to be objecting to abstraction itself, rather than to our current, potentially inferior, implementations of abstractions?
I'm not objecting to abstractions at all. I'm just advocating understanding the fundamentals first.
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.
I think you missed the point of the post you're replying to. What's the reason that you feel that you want to understand the "real technologies" that run the web? So that you can build better apps with those technologies, right?
So, what you really want to do is just build some apps, not learn CSS. See the difference?
If we had been talking about means vs. ends, I would agree.
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.
I want to understand better, but its difficult to find intermediate resources. Everything is either beginner stuff, or way to complex and over my head. (I am a back end dev, so generally don't have loads of time to spend on front end stuff).
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.
There used to be a decent standard with (x)HTML 4.1, and the commonly followed process of designing with progressive-enhancement.
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.
And so what? Did you write "HTML/CSS is mandatory" in the job description?
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.
If you get 80 applications and none of them have what you are looking for, this seems like the issue is being able to get the right candidates to apply. Or, perhaps it's just not possible to find enough people who have the skills in which case, I suppose you should train them?
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.
The contrarian argument is that this signifies an important truth, that HTML never worked the way it was suppose to. In the same way that we might argue that a misunderstood product is the fault of the designer, not the user, we could argue that developers moving away from HTML is the fault of HTML, not the developers.
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":
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.
I'm not sure I understand what you mean by a "GUI for TCP/IP" yet it seems central to your argument. I didn't realize HTML was ever intended to be anything other than structured information.
You have never seen HTML used to build something that a human might look at? What are you looking at right now? Aren't you looking at a web page? Aren't you human? Aren't you using your eyes to see what I've written? Unless you "View Source" on every page you visit, you are looking at the GUI, not the structured information.
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.)"
What a ridiculous set of requirements and self aggrandizement. I've read about aria attributes more than a few times, but do I care to remember them? No, because you set them up once and move on.
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.
Besides, all the ARIA stuff isn't free. It only benefits screen readers and bots that aren't Google's. The rejection from lack of accessibility is as strange as rejection from lack of functionality in IE 8 or less (which has perhaps 2-4x as much market share as that of all screen readers). For any website or webapp you should know your market and make the call whether you need to spend time upfront, burn the time now, or delay indefinitely or forever, on supporting these low market share alternatives.
Posts like this give me the sads. Equating disabled users with a browser that has been EOLed? Wow, just wow. Also aside from being the right thing to do, depending on who you are and where you are, it may be the law...
Styleable versions of components that aren't natively styleable (<option>, checkbox <input>, radio <input>) are another example of where ARIA attributes are helpful. jQuery's Menu demonstrates this: https://jqueryui.com/menu/ (Inspect the DOM)
I don't believe this for one second. 80 applications, seriously? You didn't even interview any of them? They don't know semantic HTML5 tags but they can wrap their head around the React ecosystem? I'm calling BS. Also what the hell is the rest of the article even about? Is he trying to teach these apparently clueless developers what they should know? Unclear. What does inequality have to do with his point? Geez.
Took me a minute to get that this is a mailing list newsletter with a random selection of interesting links from the past week, not a blog post listing things front end developers should know.
A quote: "We have an ongoing problem with growing inequality around the world and a few super rich people (latest numbers say it’s down to 65) have as much money as the rest of the world now. If we don’t change anything and do not oblige people to pay their taxes in their own countries or reject trickle-down economics as the World Bank officially declared just recently, this system will break and our own lives are likely to be affected by this."
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."
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.
I agree with this. I don't believe 80 would fail if he reconsidered his metrics.
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.
While I agree that the writer's interviewing (or lack thereof) focused too much specifics, I still have to agree with the conclusion in the title (Good HTML/CSS/A11y skills are hard to find). The majority of candidates I interview struggle to explain the difference between `.a.b` and `.a .b`. Kind of hard to write maintainable CSS without that knowledge.
How did the article make the jump from the author being unable to find their perfect candidate to the rejection of trickle down economic and asking for donations?
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've used `nav` or `section` for a long time, never found of the difference from `div`. Screen readers? Maybe for `nav`, what about `section` and other 1000 tags with subtle different semantics?
Correct me if I'm wrong but I believe there are aria attributes (e.g.: role="navigation") that can also be used as well for this same purpose. Nav is probably safer, but agreed on the CSS reset.
Do you think any of those things are difficult to learn? You certainly don't seem to think so. It's like you're looking for reasons to throw up your hands and not hire anyone.
Front-end development is broken.
Just consider how shitty html and css (and their browser support) is. Also just think about all these favicons, aria, microformats, sitemaps, sass, frameworks, cdn, you-name-it and the 10k different screen sizes.
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.
HTML takes like five minutes to learn. CSS is a lot harder, but give someone a few hours and they will also master CSS, or at least be able to Google what they are looking for.
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?
Reminds me of a fullstack bootcamp graduate I once worked with. I asked him to make a javascript interactive map (literally, copying an example from bl.ocks, but change the data file) just as a test...and after a whole day, he couldn't get it to work. But when he instantiated an entire Rails project and copy-paste the HTML inside of it as its own page, he was able to get it to work.
I would bet good money you're part of the problem. Most devs I know maintain other people's applications and don't get the opportunity to create new HTML or CSS often. It doesn't take long to get up to speed, especially with all the great online resources available. As long as the person understands the concept, give them a chance!
> I only had the chance to review their personal websites or github profiles
> 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.
The value of a developer is managing complexity and solving business needs. If that can be done with a framework and stackoverflow, then what's the problem? The one off occasion where something doesn't go right? That's why you have the one "goes deep" person on the team that you throw that issue to.
Demanding candidates understand the specifics of HTML/CSS use in your particular business context does not afford you the podium you've given yourself to castigate all the new developers starting/learning the vast world of web architecture. Have some sympathy, buddy.
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.