Most interview questions don't have a "correct" answer, per se, in the sense that point of the question is not for you to spit out a quick response and move on to the next question. The point is to engage you in a conversation about a subject (usually technical).

Many of the questions on the site you've linked fall into three broad categories:

• questions about experience with programming concepts,
• questions about academic subjects typically covered in a computer science degree program and
• questions about generalized problem solving (the kind you'd have to do at a high level before committing to code)

The first and third are the kinds that generally do not involve the interviewer expecting a single "correct" answer (although they may have an internal bias); so worry less about being correct and more about explaining yourself and your thought processes. The second kind does tend to be more about specific, optimal solutions. If you haven't completed a computer science degree you may find them daunting, but some self-study in the areas of data structures and computational theory can alleviate some of the gaps in your knowledge.

That's an interesting set of questions.

Where I would learn those topics, by section:

• Abstraction and Design: Get better by experience.
• Algorithms: Academic topic, learn most in second or third year of CS program.
• Problem solving: Most are basic math, some take some additional reasoning skill.
• Data structures: All of these are 2nd year and 3rd year CS topics.
• Scripting: Mostly just experience
• DBA: Those are basic security and database stuff, should hopefully have been covered in school.
• Data modeling, SQL, networking: all these questions are CS topics that should be mandatory in school.
• Systems design: Most are general computing questions, others should have come from early CS courses.
• APIs and specific platforms: These should all be picked up by exposure to the specific tools and languages. So mostly this judges what you learned from experiences.
• Reliability, Software Engineering, Teamwork, Judgement: Questions are about experience.
• Customer Focus, Productivity, Quality, Curiosity, Communications, Passion, culture fit: These are all personality questions.

While I know that many poor lackluster students would be unable to answer many of those questions, I expect that recent CS graduates should be able to directly answer about 2/3 of those questions, and nearly all the question that include 'write a program that..." should have been covered by at least one homework assignment. The other 1/3 could be thought through with "I'm not certain, but trying to reason through the problem I think that..."

, I expect that recent CS graduates should be able to directly answer about 2/3 of those questions, and nearly all the question that include 'write a program that..." should have been covered by at least one homework assignment.

Now I might be special but, while I've made most of this stuff (graphs, trees, cycles, search, sorting, etc) in homework, that was a couple years ago and I don't remember it. Specially since this stuff is given on the very first courses of a CS degree, and now it happens that all this time I could just call a standard library 'sort' function and it would do a double pivot quick sort without I having to even imagine how its implemented.

My point is, that its part of course homework on a degree doesn't means the student will retain it in his/her brain all the time, forever until the situation arise where he/she has to answer these questions. Specially since they're so nit picky (divide by 3 without using operators? Really?).

I find the design oriented questions much more interesting. They usually refer to problems whose solutions don't turn up as the first or second result in a single Google search.

I have to hang my head in shame because this happened to me. I had a programming test a few weeks back for a senior level position about recursive operations on trees that I absolutely tanked. The reality is in five years I've not needed to traverse a tree for anything. Given 30 minutes sitting at my desk with Google to refresh myself it would have been no problem to figure out the solution. But that is the way things go. Don't think I would want to work there anyway given the test and the type of pre screen questions asked. Another interview just had a simple FizzBuzz type programming question and an hour and half of high level program design and discussion. That is a place I would work at.

This is why I always liked the programming tests that we do here at work. We give them a "real world" example of what we do at work and a couple of days to come up with a solution. I think it easier to assess skill when the stress of the whiteboard isn't there and there is no real right or wrong answer.

I have to hang my head in shame because this happened to me. I had a programming test a few weeks back for a senior level position about recursive operations on trees that I absolutely tanked.

Sometimes it is because the interview questions are bad. I've seen that, I've experienced that, I've had it happen as both the giver and receiver.

And yet... It could be because of other factors.

That story also touches on age discrimination, which is a frustrating thing. Some companies fire people only because they are deemed too old, or because they don't fit in any more, or other age-related reasons. That is a bad thing and should be corrected.

I've worked with one developer who was getting Parkinson's disease. His hands had tremors, but he could still do the job. Ultimately it was not age discrimination that resulted in his termination, and his family was glad he could keep working as long as he did.

I've worked with other developers who were fired in their 40s. One in particular had spent several years focusing only on build systems. When the build system was replaced we tried to put him back on a mainstream team. He asked for tools development, so that was where he went. When he couldn't even handle basic tasks, he was called in and asked "You are not being productive. What can we do to help make you productive? Is there some product or some team or some language or some tool you need?" After several more months it became clear that he had lost the skills he used to have. He may have mastered a specific build tool, but he let all his other skill fade and he became useless once that specific tool was gone. Sadly he was let go not because of his age, but because he was no longer competent in general software development.

Good developers will continue to learn and grow and pick up new skills and talents. This constant growth helps everyone. It helps the company, so many companies encourage it. It helps the individual as they can add the items to their resume and work history.

Sadly, some developers stop learning new things. They stick with the languages and tools they picked up at college and never learn another language unless the company mandates it. I know many C++ developers who were let go in layoffs, chosen in part because they refused to update and learn new things, they balked at additions to the C++ language, they fought code reviews where others were using range-based loops, they refused to accept the need for constant growth.

Others will sadly move on to more and more abstractions until they can no longer work with fundamentals. Like the co-worker described earlier, they'll focus so much on one specific tool and not bother to maintain other skills, soon they become like the buggy whip manufacturers who find themselves exclusively bound to an dying product.

Perhaps it is because I do take some steps to maintain what I have formerly learned, but I do not understand how so many developers allow their skills and knowledge to atrophy.

While you might lose some details and have to address that in an interview (e.g. "Well, with recursion running the risk of blowing the stack or causing similar problems I haven't used it for years, preferring iterative solutions...") a senior developer should still be able to explain the basics and fundamentals tree traversal. For binary trees you can navigate by prefix, infix, or postfix, it may take some moments of reasoning to figure out the details but the basics should still be there.

As an analogue from that list, I haven't worked in SQL for many years but I still know what a primary key and foreign key are and how they work, perhaps because in programming the concept of mapping data from one place to another and indexing from one collection to another is such a common thing. Also on those questions while I have long ago forgotten the magic incantations for the types of joins, I do recall the effects of the joins: they are set operations for an intersection (A&B), all of one side plus the intersection (A+A&B) and the union (A + B). Perhaps when I am old enough that dementia starts settling in I will forget these types of things, but I recall these topics from decades ago. My high school age kids come to me with problems in math, history, geography, and except for a few things that have changed I'm able to explain the concepts these many years later.

If you fall into the unfortunate bin of people who became so specialized that they forgot how to do generalist work, it can make your life very difficult when the inevitable happens. When the layoffs do arrive, how will that person find work in the future?

That's the kicker, it wasn't a particularly hard problem to solve (I worked through it after the interview). One of the other things that kind of annoyed me is I verbally explained what needed to happen to get the right results I just dropped the ball on the implementation. I work for a startup so I pretty quickly got up into management and don't code everyday and it for sure has let my skills deteriorate. I learned the hard way that you still need to go back and review the old stuff so you don't forget it.

Anyone going to have a go at answering some of these?