In the murky past I wrote two article about interviewing programmers. The first covered the basics of interviewing itself and gave (hopefully) a good grounding for those who have never had to interview before. The second was all about the kind of testing you can do to filter out candidates before you commit to doing a full interview. [...] At the time I then promised to write a third section on what types of tests to use during the interview. Well I finally got round to finishing it off.

This time, he suggests things like specific language testing for your company's language of choice, an IQ test, seeing how they "pseudo code" and some psychometric testing. Basically, this boils down to measuring both the individuals potential and how good they will be in the position you're interviewing for.

My last post about back to basics covered reverse polish notation including a link to a RPN parser which I wrote to allow people to learn by example (best way in my opinion and in yours). The post got quite long and the PHP code was not really relevant to the subject so I have decided to include in this separate post instead.

There's two parts to the post - a pseudo-code explanation that an overview of how things work and the actual code, a block of code (in the 30 line area) that runs through each item and, based on a token, pushes the value into the array differently.

Early on in most people's programming careers problem solving is a large part of your day to day job. As you become more experienced you find that many programming patterns that you have used before can be reapplied. You then start working on larger and larger projects and the problems tend to be more about solving architectural problems rather than logic related ones.

Included in his list are things like "Talking it through", "Brainstorming", "Breaking it down" and "Research". This last one can be one of the most important and can save tons of time in the long run. With tools like Google and other sites, there's no reason to check before you start a project to see if there's someone out there that might have already done it (and it might be more well developed).

Writing pseudo code and program code separately simplifies the overall task by splitting it into two simpler tasks. While writing the algorithm the developer can focus on solving the problem, not how it is written in a a particular language. Once the pseudo code is written and has been checked; writing the real code becomes much simpler, the programmer is only concerned with converting the pseudo code into the appropriate program code.

Nick looks at both sides of its use and includes the good (doesn't take language-specific understanding) and the bad (could hide logic flaws that could be tragic later). He also includes a quick overview of how to write it, making sure to keep things high level and all about the structure.

What if you're using MD5 in your web application and want to switch over to another encryption method. It's actually not that hard and I plan to cover them in this multi-part tutorial (I know I planned on writing this months ago, but it's better late then never). In this first part I plan on going over updating the database structure and a 'pseudo-code' of what will need to be done.

As mentioned, he gives the outline (pseudo-code) of how the process will work - basically, creating an SHA1 hash of the MD5 and the username in a "newpassword" column added to your database.