Nick Halstead has posted part three of his series looking at interviewing programmers (here's part one and part two) with more of a focus on the details of the individual including their knowledge of code and general abilities.

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.

Nick Halstead has posted part three of his series looking at interviewing programmers (here's part one and part two) with more of a focus on the details of the individual including their knowledge of code and general abilities.

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.

As a follow up to a previous post where he discussed reverse polish notation, Nick Halstead has decided to split off the code he created for that previous post into a new, sleeker post without much of the explanation and heavy on the code.

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.

As a follow up to a previous post where he discussed reverse polish notation, Nick Halstead has decided to split off the code he created for that previous post into a new, sleeker post without much of the explanation and heavy on the code.

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.

On his blog, Nick Halstead shares a few tips he's worked up to help developers that might be having a hard time with coding issues - a few steps towards solving programming problems.

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).

On his blog, Nick Halstead shares a few tips he's worked up to help developers that might be having a hard time with coding issues - a few steps towards solving programming problems.

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).

In a post from Nick Halstead on the Programming and Management Blog, he discusses something just about every developer is familiar with - pseudo code.

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.

In a post from Nick Halstead on the Programming and Management Blog, he discusses something just about every developer is familiar with - pseudo code.

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.

Ryan Malesevich is taking a break from his look at some handy WordPress packages to share a small series on how to move from using MD5 hashes out to SHA-1 hashes for passwords in a MySQL database. He's posted part one today.

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.

Ryan Malesevich is taking a break from his look at some handy WordPress packages to share a small series on how to move from using MD5 hashes out to SHA-1 hashes for passwords in a MySQL database. He's posted part one today.

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.