My 2 cents: This is a horrible interview question. It tests arcane knowledge that takes about 15 seconds of googling, kind of like the varchar2 question in this blog post: http://www.joelonsoftware.com/articles/fog0000000073.html .
It doesn't really tell you if the interviewee can code, and it probably doesn't tell you much about how they think. Developers should be asked to write code and design systems, whether large scale services or libraries.
A valid point. I should've been more clear that this question really only makes sense when talking to a frontend dev. I always try to avoid the "varchar2" style question, a phone interview shouldn't be a trivia contest. For a frontend dev the sticky footer question can tell you more about a persons coding style and thought process. A proficient frontend dev would have an opinion about how sticky footer should be done and be able to identify common pitfalls.
Assuming I understand it correctly, the paradoxical thing about this article is that it seems to imply the engineers currently working there would have failed this interview question.
This has to be one of the worst interview questions I've ever heard. It's mindless trivia and basically slices people into two groups: people who have had to do this before and people who haven't.
Had me confused for a bit. Keeping it at the bottom is trivial. Just put it last in the html markup - right before </body>.
What you meant to say seems to be "at the bottom of the screen", which prompts more questions than answers.
Then again, maybe I'm misunderstanding your intentions entirely, since you state that your naïve solution was to use position:absolute. But then in the next paragraph, you talk about position:fixed. Was the absolute-part a typo?
I'm still confused though, since the linked jsFiddle uses position:absolute. Clearly that would never work - That's pretty basic html/css wisdom. I would expect position:fixed to do work though, although your post suggest that that might not be the case on all platforms. I guess I wouldn't realise that until I began testing on a broader range of devices than the normal development stack holds.
position: fixed is if you actually want the footer to always be visible, with the main body content scrolling out from under it. To my knowledge, this works across all devices.
The goal of this snippet is to have the footer always below the content, but in the event the content is shorter than the page height, the footer should still be placed at the bottom of the page.
Really Javascript isn't a terrible solution here, since it only needs to be run on load and on window resize (rare events), but the CSS is indeed nifty and worth knowing it exists.
Agreed with siblings stating that the question is arcane, Googleable best practices knowledge. Any time I want to find the answer to something like this, I Google it.
The author should ask themselves honestly if they ask this question just so they can quickly say, "Nope, wrong! Your answer doesn't cover [X number of unstated assumptions]." While I understand things are complex, my first answer would have been something along the lines of position: fixed; bottom: 0;. If that makes me wrong because it doesn't work on [Y smartphone] or [Z tablet], then two things need to be done to make this question worthwhile:
1. State your assumptions and intended audience up-front.
2. Allow the candidate to Google.
If the candidate is allowed to research and put together a comprehensive answer based on the knowledge they've gathered, that turns this question into a much more insightful one.
This article made me feel like a crotchety old programmer for the first time in my career as I cringed at the use of the phrase "great engineer" to describe someone capable of discussing a markup/stylesheet problem during an interview. It's all relative, I guess.
I know the feeling all too well. Managing cross-platform frontend development has become an incredibly intricate, so much so that anyone who can bend the browser to their will deserves the "great engineer" stamp.
This is one of the more mindboggling snippets of CSS you'll ever see. It's up there with techniques that keep two columns the same height without using Javascript or a <table> element.
I've implemented this before, but still wouldn't be able to produce it on the spot without Googling. This post encouraged me to take a deeper look.
The craziest part is the #wrapper element, which uses a nifty hack to support old and new browsers. Old browsers don't work with css min-height, but they do allow the height property to expand. Moreover, old browsers will ignore an "important!" tag if the same property is addressed later in that selector.
It's a perfect storm of dumb luck that "min-height: 100%; height: auto important!; height: 100%;" actually manages to do what you want, for this exact scenario, in all browsers. That line looks pretty stupid to most modern css devs.
Here's an arguably cleaner approach that I believe will work for most modern browsers (I think after IE6, but could easily be mistaken). No need for the wrapper around all content, but you still need that darn "push" div. Actually now that I think about it, it might even work for older browsers if you add "height: auto important!; height: 100%;" to the body. Maybe someone can test?
http://jsfiddle.net/A3BLm/1/
This question/post highlights one of the reasons the "no karma score" here at HN is not so great (or perhaps could be improved). We, the HN community, might vote a particular answer to the top but OP/author will not necessarily know that this comment is at the top of the page for any particular reason.
In other words, let's say that @gfodor's comment ("This has to be one of the worst interview questions I've ever heard.") gets 500 upvotes. It will then get ranked first, meaning that it will be the first comment shown when the page is loaded. But that is not obvious - there are no other visual cues that confirm this information. The only way to know this is to have either looked through the source code, or to have been around and seen this question asked/answered.
So this valuable info (that 500 other HNers also thought this was a terrible question) is 100% lost to everyone. No one knows how popular it is. The OP cannot learn that his opinion is thought to be a terrible interview question.
I wish we had a better way of doing this... Maybe OP can see comment scores but no one else can? Dunno...
The problem with this question is there is no way to explore a candidate's thought process. They either know it because they just so happen to have needed a sticky footer or they don't. They could guess, but like the author says the intuitive solution isn't going to be right anyway.
Also, obviously this question is biased towards front end developers.
I hope the real answer isn't "Do this to create a sticky footer" but "no one wants sticky footers; they are semi-evil; here's what I'd do to persuade the customer / PHB that sticky footers are a stupid idea".
Interview questions should test the thinking ability of the candidate. You should be looking to see how they solve problems. This is mindless trivia, the answer should be "by googling".
OK, I'll drop the bomb, because I've enough of these propagandized half-truths about "Interview Questions"!
TL;DR: The sympathic interviewer is not qualified enough to extract results out of response, but capable of making (random) gut decision. Just like all the others who write about the same "problem scope" (hiring).
Questions and statements can provoke a think process, but is the person who provoked the think process qualified to do interviews? Let's solve the question arised from the ground up! The interviewer must have studied "Communication studies" or at least have significant knowledge in the field. Now don't underestimate that statement, even if it sounds far fetched. We already know that proper homework in Communication studies (and UX Design) was what made Apple a billion dollar company (amongst other things). The technology altough a key driver, was made by much larger companies too, without comparable success.
To put it differently: Just as a Software developer isn't qualified to do medical decisions, a Developer, CEO or other Interviewers can't decide about interviews like a communications research specialist. Let's not forget that everyone instinctively recognizes good music. But what makes music sound good? The Geometry of Music can provide accessible information using a revolutionary geometrical approach to music theory explored by Tymoczko [1]. Now you might have an idea on how much more there is to it below the surface.
"The principal idea is that defining something as working or not may sound simple, but is of complex nature."
Don't forget that regardless what has been asked or stated, the think process including the outcome is there to reveal the qualities of the PoI. But an interviewer, even if he's a developer himself, doesn't scientifically qualify to make statements appear like wisdom[2], whereas it's just a gut decision. No matter which fix-points an interviewer chooses for job qualifiers, it will not be complete without a proper analysis and reflection of the communication process. I mean, just make the effort and take a read about Harald Lasswell and Communication studies to get a broader understanding of what is neccessary for fundamental knowledge about what is working and what is not.
No excuses if I sound like a diva, I didn't have my mars yet.
Here's what I'd answer to the question:
CSS Media Queries (iPhone), CSS Expressions (IE), Basic CSS Knowledge (Positioning) and the most important thing: "Do you actually want the job and is the offer good for you?" (Self-esteem)
Because coding isn't Rocket Science, applying UX to the interface would come close to that though (when done scientifically).
It doesn't really tell you if the interviewee can code, and it probably doesn't tell you much about how they think. Developers should be asked to write code and design systems, whether large scale services or libraries.