Comment On Good Answer... Perhaps TOO Good

Peter B. was an out-of-work PHP developer looking for contract work in early 2005. A recruiter he'd worked with in the past emailed him some information regarding a possible position. Reading the job description, Peter thought he'd be a good fit, so he submitted his resume and got a response via email a few days later. [expand full text]
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5 | Page 6 | Page 7Next »

Re: Good Answer... Perhaps TOO Good

2007-08-30 15:34 • by omfg. (unregistered)
I'm in the wrong industry. I hate computers.

Re: Good Answer... Perhaps TOO Good

2007-09-03 18:14 • by Dallas Freeman (unregistered)
OMG, bad luck buddy. I didn't see that one coming.

Re: Good Answer... Perhaps TOO Good

2007-09-06 09:56 • by Gilles (unregistered)
It reflects pretty well the sad state of IT recruitment. Bounty-driven recruitment agencies are the industry's number one plague.

People who don't understand a thing about IT are making decisions on who gets through these screening processes.

You end up as a candidate with your CV not even reaching employers that have positions that fit you perfectly because "you're missing one keyword". And as a company you end up receiving people for interviews that don't fit your profile at all, but that made it through the net by bloating their CVs with exagerations.

It's so revealing when "head hunters" call you for a position. During the part of the conversation that makes you look like the ideal candidate you can hear the "sweet, I'm getting my $1000 bounty today" tone of voice. But as soon as you don't tick one of their key points you're treated as a second-class citizen and you never hear from them again.

I loathe incompetent recruitment agencies.

Re: Good Answer... Perhaps TOO Good

2007-09-16 15:55 • by Jeff Barron (unregistered)
153480 in reply to 150672
Chris:
Jesse:
WTF:


SQL queries are rarely generated without some sort of dynamic data to alter their structure, so this is a very common task that I've used in just about every web application I've written.


Can I say SQL injection? That would be why I wouldn't have hired him..

Oh piss off!

The guy can stretch what is a very simple concept of concatenation into many paragraphs, including the syntax of other languages and a common SQL example. He even gave an example of $User object, all of which shows he's at least half way competent.

While I wouldn't automatically assume he was aware of preventing SQL injection, I wouldn't automatically dismiss him of not knowing about it simply because he didn't mention it here.

If you're the type of person that dismisses someone because they write an essay but miss out a word, then I really hope I never have to work for you.


SQL Injection is very serious and I certainly wouldn't have dismissed the candidate but I'd make a note to have a talk with him about the issue just in case he wasn't familiar with the threat. But if they thought he copied his answer or it was just to "ingenius" for him to come up with on his own then the guy is way better off for ignoring such an ignorant company. Probably a spam agency, porn site or viagra dealership. lol.

Jeff

Re: Good Answer... Perhaps TOO Good

2007-09-19 14:10 • by Mkdir (unregistered)
Once in an interview I was actually asked to define what string concatenation was and I laughed out loud. Once I contained myself, I asked if they were really serious about that question and they responded that they were. Of course I answered and after getting the job, one of the interviewers said that my disbelief about something so simple was exactly what they were looking for.

As a side note, that also was the interview that I went through half of with my fly open. Thankfully they didn't notice and I was able to discretely zip up while pulled up to the table.

Ahhh, memories.

Re: Good Answer... Perhaps TOO Good

2007-09-20 05:31 • by Kalaith (unregistered)
All stuff i know

but i can't answer questions that well thought thru *claps*

My answer would have been along the lines of
"joining two strings togheter" like
"hello" + "World"

lol

Re: Good Answer... Perhaps TOO Good

2007-10-28 21:13 • by Fuck Yeah (unregistered)
158942 in reply to 150964
<b style="color:black;background-color:#ffff66">Horseonovich</b>:
Those Guys are Assholes


Fuck Yeah

Re: Good Answer... Perhaps TOO Good

2007-11-03 14:25 • by Nico (unregistered)
Hahaha, i knew that he will be rejected. To complicated answer.

Re: Good Answer... Perhaps TOO Good

2007-11-20 11:42 • by john celenza (unregistered)
Plagerizing is a valuable talent. At least twenty percent, if not more, of any code i produced has been lifted from earlier work or the internet. If a company is big on paying for wheel reinvention, you have to wonder about the company.

Re: Good Answer... Perhaps TOO Good

2007-12-04 14:17 • by ginger (unregistered)
164054 in reply to 150643
its a good job.!

Re: Good Answer... Perhaps TOO Good

2008-01-08 09:04 • by Yanman (unregistered)
"on a PB349 microprocessor, if memory address 0xa9f00c contains a MOV instruction to memory address 0x8ad9da, what is the magnetic force dispensed by a 64KB memory module for the next 600 instructions?


Around 0.83E^-10 Newton.

Re: Good Answer... Perhaps TOO Good

2008-01-23 19:01 • by Brunty
I can honestly say I'm shocked, "They think you plagiarized it. I'm sorry." - they've got no definite proof - but I think Peter's better off without that company!

Re: Good Answer... Perhaps TOO Good

2008-02-27 13:46 • by Kireas (unregistered)
179570 in reply to 150644
...I honestly can't think how I'd make a script work without dyanamically driven data. I'm not a professional (I.E. I don't get paid), so perhaps that's it.

But why don't you think before you say something like that? Can't you sanitize the data before putting into the query? I know I can.

Re: Good Answer... Perhaps TOO Good

2008-04-10 15:49 • by Brandon (unregistered)
189121 in reply to 150651
Dwayne:
Jesse:
WTF:

SQL queries are rarely generated without some sort of dynamic data to alter their structure, so this is a very common task that I've used in just about every web application I've written.

Can I say SQL injection? That would be why I wouldn't have hired him..

Can you say "string escaping"? Preventing injection attacks is roughly as difficult as sitting on a couch.


Can I say *Insert spiffy new string lingo*? *Insert spiffy explanation while laying on the sarcasm so that the previous poster feels studpid*

Re: Good Answer... Perhaps TOO Good

2008-05-31 00:07 • by maomwl (unregistered)
Well perhaps if he had explained the uses more in the context of "how he had used it in the past", it would dispel suspicions that he just plagerised it...

Re: Good Answer... Perhaps TOO Good

2008-07-01 04:58 • by Johan (unregistered)
Hello! I want to inform you about new interesting project.

"DesireFotos" is intended for processing digital photos in accordance with your wishes. This is initiative of professionals with wide experience in photography and related activities. You can use "DesireFotos" to make your photos qualitative. Do you think there is nothing to improve in your photos? It's not so!

Go to www.desirefotos.com and make sure ourselves.

If you want to have really good photos, this service for you!

Re: Good Answer... Perhaps TOO Good

2010-09-07 12:32 • by me (unregistered)
Good answer but your query is open to sql injection.

Re: Good Answer... Perhaps TOO Good

2010-12-30 15:46 • by HonoreDB
The answer is not open to SQL injection. It's concatenating in a server-side variable, and there's no reason to assume user ids can be be arbitrary strings.

Re: Good Answer... Perhaps TOO Good

2011-12-13 07:33 • by someone (unregistered)
My way of preventing sql injection,
is to prevent the ' and " of even making it to the query!
e.g:
Say your db table looks like this:
+----+------+
|USER|PASSWD|
+----+------+
|JOE |<sha2>|
|JOHN|<sha2>|
+----+------+

(replace <sha2> with an sha2 hash of their password)
In books they tell you to do it this way (my sql is a little rusty, forgive me for that):

$sql = "SELECT USER FROM USERS WHERE PASSWD=SHA2('$password') and USER='$username';";

While i usualy do (the table has an added column containing an sha2 hash of the username called HASHUSER):

$hashuser = sha2($username); //this is php, sha2 is an function which i'm not feeling the need for to discuss (it's pretty obvious)
$hashpass = sha2($password);
$sql = "SELECT USER FROM USERS WHERE PASSWD='$hashpass' AND HASHUSER='$hashuser';";
//process the sql and split the columns in arrays (1 column per array, the array contains the resulting rows), in this case this results in 1 array containing the column USER and the entry's are the items sorted by row
if ($result_USER[0] == $username /*and some other login logic (user priv's, already logged in?, etc)*/)
{
//do stuff because we're logged in!!!
}
else
{
//do stuff when login fails
}

See? No bad chars make it to the sql query, only sha2 hashes.
And as double safety, the input username has to match the unencrypted one retreived by the query (so collisions are also taken care of).
That and other custom (as in: case specific) logic make logins secure (that and a good ssl connection, verified before even attempting an login of showing a loginbox).

Re: Good Answer... Perhaps TOO Good

2012-10-01 05:28 • by Pakistan Drama (unregistered)
Totally agree with your suggestion... Very nice post and good information here... Thanks for posting that....

http://teavdrama.com/
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5 | Page 6 | Page 7Next »

Add Comment