Reminds me of myself.

When someone told me what a singleton was, it reminded me of some 'ugly hack' I had done to make something work. Then I realized that it was exactly what a singleton was.

That's also why I always refer to myself as being able to write code, but never as a programmer.

I would be worthless in a large team because, as soon as someone says something and everybody goes back to work, I'd be the one asking 'what did that mean exactly?' and once I would get the proper explanation I'd feel like I've wasted both our time for something simple.

Truth is, someone like you (or me) end up costing a lot. It is possible to have a lot of practice but too little theory, and this hinders proper communication.

In my opinion core algorithm development on computer (not on paper) should be the best way to test the competence and intelligence of a developer

This doesn't just sound like you don't know specific things like the linked list loop problem. It sounds like you don't place much value in understanding more than whatever it takes to get your code to run. That doesn't make you a person who I would want to work with.

Its the bad interviewing methods of the industry that is killing my skills,

Originally I was top a class programmer. Then I had a break lasting several months (supposed yo be a temporal quit - due to family issues). Then I couldn't get in any more.

But I still kept up by developing great personal projects (a RT 3D photographic scanner- for example), Except that through the years, as I concentrated more on development, My theoretical rehearsing stop, that affected interviews. My coding skills remained top class at first until i'm forced to work outside the industry 9 hours a day, 5/6 days a week (in a retail, restaurant - find it boring, not my calling), and now, after some few years of that , even my programming skills (and analysis skills) is now starting to get extremely rusty.

Its a chain effect that I wouldn't wish on my enemy

Yes, now i realise the solution was extremely simple, but i was attending to the forum during breaks in my long shift, was tired, lacked patience... if I'd known my judgement would be affected that much i would have waited for my day-off

I cannot imagine ever hiring for a programmer position without having the candidate white board one or more programming problems.

I say this, because I've been the "technical interview" for people being hired in as programmers who really were not at all qualified. The resume looked great, they absolutely nailed the "let's talk about process, and how we work together" process interviews, as well as the "let's talk about programming without actually doing any" interviews. And then I asked them to whiteboard, and they absolutely cratered.

One of the questions I used to use when looking at candidates who listed on their resume a proficiency with C/C++ was a simple opener.

Please implement this function:

/* Implement a simplified version of integer to ascii, supporting only base 10, and assuming a 32 bit value on a 2s-Complement architecture */
char * itoa(Int32 value)
{
}

This is not a hard question per se (as with most of my interview questions, I stole it from questions I was asked in an interview). There are a couple of ways to approach it, and while there is a corner case, I don't hold missing it against the candidate. Getting it on the other hand is a bonus. Mostly, I want to see you approach the problem.

And yet, one candidate confidently wrote this:

char *itoa(Int32 value)
{
   return (char *) value;
}
 

Not only did he confidently write it, it took a fair bit to convince him he was wrong. Even with a lot of prompting, what was supposed to be the first 15 minutes of the interview took the whole hour, and he never did get the problem solved.

And that is why I'll always want anyone being hired for a development role to actually write code as part of the interview. Because I've *seen* people with the right resume say all the right things, and flunk the ability to actually write anything. I no longer assume "basic coding competence".

[As a side note, having been on both sides of whiteboarding questions, it is *always* easier to spot the bug while you are sitting there watching them write. That's why the interviewer always seems to have a laser focus on the bug when you haven't seen it. As a candidate, as soon as you finish writing it down (and you should talk about what you are doing and why as you go), say something to the effect of "Now to step through this and look for bugs", and out loud start debugging what you wrote with example cases.]

hope you get good work.

I am a software engineer in the gaming industry, and I've been interviewing software engineering candidates for about 4 years. If you're asking questions like the one posed in this topic, you need to understand that you are competing with people who have the skill sets you claim to lack. If you can't deliver on other fronts, your only alternative is to prove that you are significantly better -or- significantly more experienced as a technical problem solver. Go out of your way to demonstrate a deeper knowledge of the systems being discussed. When you hear a question like the previously described "how do I detect an infinite loop in a linked list traversal?", you should understand that on the surface this is not a difficult algorithmic question. You need to dig deeper, and find ways to impress the interviewer. Under what scenarios could you optimize the standard algorithm? Could the application benefit from only executing this logic in a Debug configuration? Can you explicitly describe the ways in which your proposed implementation takes advantage of modern hardware optimizations? Notice I didn't say a single word about anything theoretical - I never even mentioned the infamous "big-Oh". There's a big difference between answering "use a debugger," and using an otherwise mundane question as a launchpad into demonstrating a detailed understanding of temporal and local caching. Most questions I ask in an interview setting - even ones that are purely about fundamentals - are intended to give you opportunities to demonstrate that you are thinking about more than the rest of the pack. Those few who can do so always hear back from me.

If you can't do the theory, you can still get a job. You can even get a very good job! However... in order to do so, you're going to have to steer the interview in the direction of your strengths. If those strengths aren't there, unfortunately despite your personal opinions... you are simply less qualified than your competition.