Thread: Re: Interview questions?
From: brion@estaffing.net
Odd request.
I am not a developer myself, but would like to know what kinds of technical
interview questions (and possible answers) I can ask developers to try to
find someone that really knows what they are doing.
I need to hire a postreSQL/php developer for some maintenance and upgrade
work on my site.
The site is fairly sophisticated. I think it was built on postreSQL 6X and
PHP. When we loaded to the server, we ended up with 7X and there seems to be
a few wrinkles with the code on the newer version.
A few of the main issues that I am going to need this person to deal with
are:
1) On one custom form, I am getting the error - "no OID was passed"
2) Being able to search "non-case sensitive" AND being able to hold the
order of the results from page to page.
3) Using an "apostrophe" anywhere in any of the forms, creates a page error
4) Every time I edit one of the forms with a url, an extra "http://" gets
put into the address
5) On several forms, if you have not completed all the information, and you
get an error message, ALL of the info that was input during that session, is
cleared.
I am nervous to have a complete stranger working on the code, but the
original developer is no longer available.
I am guessing most of these should be fairly straight forward fixes.
So any help on screening questions that will help me find a developer
capable of solving these problems, is most appreciated.
Regards,
Brion
On Wed, 17 Sep 2003, Brion Wikes wrote: > Odd request. > I am not a developer myself, but would like to know what kinds of technical > interview questions (and possible answers) I can ask developers to try to > find someone that really knows what they are doing. > > I need to hire a postreSQL/php developer for some maintenance and upgrade > work on my site. > > The site is fairly sophisticated. I think it was built on postreSQL 6X and > PHP. When we loaded to the server, we ended up with 7X and there seems to be > a few wrinkles with the code on the newer version. > A few of the main issues that I am going to need this person to deal with > are: > > > > 1) On one custom form, I am getting the error - "no OID was passed" > > 2) Being able to search "non-case sensitive" AND being able to hold the > order of the results from page to page. substitute ilike for like or ~* for ~ in the where clause for this one. > 3) Using an "apostrophe" anywhere in any of the forms, creates a page error Turn on the magic_quotes_gpc, and magic_quotes_runtime parameters to fix this. You may only need the first. Test it both ways. Either that or put addslashes/stripslashes all over the place. > 4) Every time I edit one of the forms with a url, an extra "http://" gets > put into the address simple fix, the code is probably programmed to prepend http://. The old code may have been programmed to remove the http:// during display but got broken somehow. > 5) On several forms, if you have not completed all the information, and you > get an error message, ALL of the info that was input during that session, is > cleared. > > > > I am nervous to have a complete stranger working on the code, but the > original developer is no longer available. > I am guessing most of these should be fairly straight forward fixes. > > So any help on screening questions that will help me find a developer > capable of solving these problems, is most appreciated. Ask them what they think of these issues and what the likely causes are. any competent PHP/Postgresql programmer should be able to fix 2, 3, or 4 in an afternoon.
On Wed, 17 Sep 2003 19:44:42 -0700 "Brion Wikes" <brion@estaffing.net>
sat down, thought long and then wrote:
> UntitledFrom: brion@estaffing.net
>
>
> The site is fairly sophisticated. I think it was built on postreSQL 6X
> and
>
> PHP. When we loaded to the server, we ended up with 7X and there seems
> to be
>
> a few wrinkles with the code on the newer version.
>
Hi,
are you sure the odds are (only) resulting from a different database
version? I am just lifting a PHP application from 4.0.x to 4.3.x and
that seems to need a big rewrite of a lot of code. Even a lift from
4.0.x to 4.1.x broke several modules, and I have not found all the
reasons yet. I have the same problem you have: The original developer
isn´t available any longer, and I have to update and fix that
application myself.
I used to be a PHP-user for a long time, but these problems with
different PHP versions have brought me back to the usage of Perl CGIs
with FastCGI. Never had any problems with that combination yet,
excellent speed, excellent stability, no release version related
problems. YMMV.
Regards,
--
Frank Finner
Memory follows memory, memory defeats memory; some things are banished
only into the realms of our rich imaginings - but this does not mean
that they do not or cannot or will not exist - they exist! They exist!
(M. Moorcock, "The Revenge Of The Rose")
>I used to be a PHP-user for a long time, but these problems with >different PHP versions have brought me back to the usage of Perl CGIs >with FastCGI. Never had any problems with that combination yet, >excellent speed, excellent stability, no release version related >problems. YMMV. > > You can run into the same problem with perl. It is just a matter of knowing what you are doing (this is not a slam). It is my experience that there are a lot of would be programmers who claim PHP experience that really don't know what they are doing. Perl at least, to some degree can be intimidating and will scare alot of those same people away. Sincerley, Joshua Drake >Regards, > >
On Sat, 20 Sep 2003 10:33:53 -0700 "Joshua D. Drake" <jd@commandprompt.com> sat down, thought long and then wrote: > > >I used to be a PHP-user for a long time, but these problems with > >different PHP versions have brought me back to the usage of Perl CGIs > >with FastCGI. Never had any problems with that combination yet, > >excellent speed, excellent stability, no release version related > >problems. YMMV. > > > > > > You can run into the same problem with perl. It is just a matter of > knowing what you are doing (this is not a slam). > It is my experience that there are a lot of would be programmers who > claim PHP experience that really don't > know what they are doing. Perl at least, to some degree can be > intimidating and will scare alot of those same people away. > I agree, and I think this holds true for most programming languages for which there is no real well defined standard (as is for C for example, but again not for it´s additional libraries), but updates for PHP are extremely frequent compared for example with Perl. I use Perl 5.6 and 5.8, and I have found absolutely no backward compatibility problem (at least not yet :-) ), and I use PHP 4.0.6 and 4.3.3, and have to fix lots of backward compatibility problems there, sometimes perhaps simply caused by unclean (but in earlier PHP releases allowed) programming style. Between these releases is a period of two years, with Perl and PHP, but PHP released a lot more versions during that time than Perl did. And they still discourage the usage of PHP with Apache 2 (see http://de.php.net/install.apache2), which is for me also a major drawback to use PHP. But regardless, what programming language and environment you use: The main point is: If you have problems with an application on different environment, take everything into account as a reason: Database, programming language, external modules, webserver, even different browser releases can cause strange problems (for example, if you use Javascript for input checking). Usually problems are caused by more than one reason at the same time... Have a nice weekend, Frank.
On Fri, 19 Sep 2003, Frank Finner wrote: > On Wed, 17 Sep 2003 19:44:42 -0700 "Brion Wikes" <brion@estaffing.net> > sat down, thought long and then wrote: > > > UntitledFrom: brion@estaffing.net > > > > > > > The site is fairly sophisticated. I think it was built on postreSQL 6X > > and > > > > PHP. When we loaded to the server, we ended up with 7X and there seems > > to be > > > > a few wrinkles with the code on the newer version. > > > > Hi, > > are you sure the odds are (only) resulting from a different database > version? I am just lifting a PHP application from 4.0.x to 4.3.x and > that seems to need a big rewrite of a lot of code. Even a lift from > 4.0.x to 4.1.x broke several modules, and I have not found all the > reasons yet. I have the same problem you have: The original developer > isn´t available any longer, and I have to update and fix that > application myself. > > I used to be a PHP-user for a long time, but these problems with > different PHP versions have brought me back to the usage of Perl CGIs > with FastCGI. Never had any problems with that combination yet, > excellent speed, excellent stability, no release version related > problems. YMMV. Perl 6 will cause you pain. There are plenty of changes that will cause much perl 5 code to break in Perl 6. The sad fact of the matter is tha tin order for a language to grow, some things have to break, be it PHP, Perl, or Java. Once it's been stable a long time (C for instance) the changes drop off, but even today changes in gcc cause older code to break.