I am interviewing for a position which has come up in my company next week and I need to come up with some coding questions to evaluate the candidates.

I thought about coming up with a few questions to ask during the interview but then thought it might be better to come up with a short script with some problems to find, and give each candidate 10-15 minutes to look through it so as not to feel too much on the spot. What do you guys think of this approach? It does seem a bit rigid, maybe an informal discussion about coding techniques would be better.

Anyway, here is the script. There are about 8-9 flaws and security issues to find. I don't expect people to find them all. Answers to come 😉

The URL to the script: http://www.mysite.com/index.php?page=userdetail&id=1

Some php.ini settings:
display_errors On
allow_url_fopen On
allow_url_include On

File index.php

<?php
// Load header, footer and page content
require 'header.html';
require $_GET['page'] . '.php';
require 'footer.html';
?>

File userdetail.php

<?php
// Select users credit card information from the database
$sql = 'SELECT * FROM the_table WHERE id = ' . $_GET['id'];
$connection = mysql_connect( 'db_uri', 'username', 'password' );
mysql_select_db( 'the_db', $connection );
$resource = mysql_query( $sql );
$row = mysql_fetch_assoc( $resource );

// Display the page
foreach( $row as $key => $value )
{
  echo 'Card number: ' . $row['cardnum'] . '<br>';
  echo 'Start date: ' . $row['startdate'] . '<br>';
  echo 'End date: ' . $row['enddate'] . '<br>';
  echo 'Security code: ' . $row['seccode'];
}
?>

This is just sample code, it obviously won't run so assume it parses and any credentials are correct.

I would love to know other peoples experience from the "other" side of the table. I've only ever been a candidate and never an interviewer. It's suprisingly nerve racking.

-Paul

    While the "what's wrong with this code" approach has a certain value, especially if the candidate will be involved in a lot of maintenance activities; I think I'd want to spend a greater part of the available time finding out how they would solve problems, perhaps by giving them some functional requirements and asking how they would design, implement, and test their solutions.

      Elizabeth - I did find that site but I want to avoid that sort of quesion as I don't think it tests much other than general knowledge. Very good point about OSS though, I will definitely ask that.

      Nog - I think you are right. That sort of problem has no definite "correct" answer and should prompt some discussion about techniques. I'll try to come up with some scenarios.

      Thanks guys.

        Shrike wrote:

        Elizabeth - I did find that site but I want to avoid that sort of quesion as I don't think it tests much other than general knowledge. Very good point about OSS though, I will definitely ask that.

        Nog - I think you are right. That sort of problem has no definite "correct" answer and should prompt some discussion about techniques. I'll try to come up with some scenarios.

        Thanks guys.

        I was involved in a lot of interviewing a few years back, though it was for functional testers, so a bit of apples and oranges. I have to admit that it was not the most comfortable of activities, particularly as I had no training in it, and my only prior experience was from being the interviewee. What I did learn from trial and error was that worked best for me was to try to ask leading questions that would get the applicant talking. Even if it led us into some tangential subjects, my first goal would be simply to get them talking.

        Then when they had loosened up a bit (and how fast and how much they do so varies widely between applicants), I'd start focusing on getting them to tell me what sort of things they did in their prior jobs, and try to get them to talk about what they felt were their biggest contributions/success stories there. By then we should have a good base of communication (and if not, it was probably time to write that one off, anyway), and I'd throw in the handful of prepared technical questions I had.

        We also had a little written test we gave them (I don't remember where it came from) to have them demonstrate their knowledge of software testing practices and procedures, and a bit of problem solving in terms of developing some test cases; but I found that the test mostly just gave me a pass/fail sort of result: either they had some knowledge or they didn't, but I didn't find it much use for ranking those who made the final cut from the interview.

          Shrike wrote:

          I'll try to come up with some scenarios.

          This is where one's own experience can come in handy. Maintaining db integrity in the face of polymorphic ORM?

            Write a Reply...