4 ms·

"I used MySQL for years, long ago, and never wrote a join." Scary! I wonder about your definition of "used", if you used an RDBMS in a non trivial app "for ye

"I used MySQL for years, long ago, and never wrote a join." Scary! I wonder about your definition of "used", if you used an RDBMS in a non trivial app "for years" and never wrote a join! The database design must be very ... unusual :-). And this was in the days before ORMs :-D. " Then ORMs came along and handle joins automatically, so I've still never written one. " I've never yet seen a non trivial RDBMS based app where the existence of an ORM absolved developers from having a good grasp of SQL when they needed to drop below the abstraction layer provided by the ORM. "So not being able to do it without looking it up doesn't really tell you anything." It does, really! ;-). "PG, RTM, and TLB would probably fail your test -- they don't use SQL, they use flat files." The interesting thing about this statement is that it shows one way out of potentially being asked to code on a whiteboard/over the phone. If you have a PhD' from MIT and/or have a strong track record of writing Open Source software, creating and selling a startup, build robots (and electric unicylces ) for fun etc, in other words, if you can show , well before the interview, that you are as good or better than the job demands, you are very unlikely to face the "find the longest subsequence in a string" or "write a join" type questions. But then if you could do all that why would you look for a job? In my case, after writing some open source software, (and posting an url as the first thing in my cv) I've found that these kind of elementary questiong simply drop away. When a few thousand people use your code everyday, people know you are good. The OP's post is about when all you have is a cv that looks like the last 100 cvs you reviewed, and people who can't answer simple questions about how to write a join (hence his depression).

enjo 17y ago
I would fail if this was a 'live' screening. It's rare that I write SQL by hand, and remembering the syntax for a JOIN is something I pretty much always look up. I just don't do it by hand very anymore. I'm a very good developer (my track record would suggest as such), but I would fail at least one part of this test due to the simple inability to remember elementary SQL syntax. The interesting thing about this statement is that it shows one way out of potentially being asked to code on a whiteboard/over the phone. If you have a PhD' from MIT and/or have a strong track record of writing Open Source software, creating and selling a startup, build robots (and electric unicylces ) for fun etc, in other words, if you can show , well before the interview, that you are as good or better than the job demands, you are very unlikely to face the "find the longest subsequence in a string" or "write a join" type questions. But then if you could do all that why would you look for a job? That's just not true, particularly at the larger companies out there. Amazon, for instance, has a rigorous process that you can't (more or less) circumvent. It involves a lot of saying algorithms over the phone. It was one of the most challenging interviews I've done in my life. Not because of the content, but because of the method.
- plinkplonk 17y ago
  "That's just not true, particularly at the larger companies out there. Amazon, for instance, has a rigorous process that you can't (more or less) circumvent. " "more or less" is key. If someone at the level of PG or RTM (or Linus or Hejlsberg, say) were to apply to Amazon (or Google or Yahoo), I am sure they aren't going to be asked to code "subsequence of a string" on the phone! They'd no doubt get a good interview but i highly doubt thatthis kind of "ask trivial questions" interview would occur. The purpose of such phone interviews is to eliminate clueless people who have the knack of writing good resumes , the "all hat and no cattle" types. I was specifically responding to this sentence "PG, RTM, and TLB would probably fail your test". I doubt that somehow!
  - vax_11 17y ago
    > I was specifically responding to this sentence "PG, RTM, and TLB would probably fail your test". I doubt that somehow! But you'd be wrong.
jasonkester 17y ago
"I used MySQL for years, long ago, and never wrote a join." Wow. Note to self: start asking candidates to write SQL in interviews. It had just never occurred to me that people who spend their entire lives talking to databases wouldn't know how to talk to them directly. And really, you can get pretty much any piece of information out of a database using just four keywords. It's the least memorization of any language in history. SELECT, FROM, WHERE, and for extra credit, LIKE. That's it. That'll get you any non-aggregate dataset you could want, joined or otherwise. Learn IN and GROUP BY and you've got everything else you'll ever need for reporting. It's just the simplest language ever.
- vax_11 17y ago
  > It had just never occurred to me that people who spend their entire lives talking to databases wouldn't know how to talk to them directly. You're begging the question. Most people who use databases don't "spend their entire lives" talking to them. Of course I've talked to databases "directly", tuned them, "alter"ed them, indexed them, replicated them, and so forth, but just happened to use logic at the application level instead of the SQL level for JOIN functionality.
  - james2vegas 17y ago
    Ok so hopefully the places where you used to work hired someone that wouldn't write horribly inefficient client-side code to join two tables together when its a SQL RDBMS, and sped up those applications|sites considerably.
- Flemlord 17y ago
  > Note to self: start asking candidates to write SQL in interviews. Heh. Quite a few people (~20%) take the attitude of the parent poster, saying they're not solid on SQL since they've been using ORMs for a while. So I ask them to write the same select in LINQ or their ORM language of choice. Not a single one has been able to do it.
vax_11 17y ago
> if you used an RDBMS in a non trivial app Depends on what you mean by "trivial". You can use a database for most of the things most websites use them for without ever using a JOIN. It just takes application logic instead of SQL. Sites like this aren't exactly heavy on the SQL. This site doesn't even use SQL. Something like Reddit or Slashdot would, but still wouldn't need JOINs. > I've never yet seen a non trivial RDBMS based app where the existence of an ORM absolved developers from having a good grasp of SQL when they needed to drop below the abstraction layer provided by the ORM. You don't have to drop below it; you can go "above" it into the application layer. > If you have a PhD' from MIT and/or have a strong track record of writing Open Source software, creating and selling a startup, build robots (and electric unicylces ) for fun etc, [...] But then if you could do all that why would you look for a job? Let's consider the case of someone with a PhD who ISN'T famous, and then you give him some kind of SQL test and he fails. "Man, what a load of bullcrap his PhD is! He can't even do a simple JOIN!" There are a lot of people who aren't "PhD millionaires" or famous open-source magnates and yet are vastly capable. A lot of them don't write joins. And a lot of people who CAN write joins can't do a bunch of other stuff. You know what else PG doesn't do? CSS. He runs a website but doesn't use CSS or SQL. So, once again, the danger of using any litmus test is you can end up filtering out extremely capable people who don't do X (but could obviously pick it up quickly), while passing minimally-capable people who CAN do X.
- plinkplonk 17y ago
  "Depends on what you mean by "trivial". " Anything that has more than say, 2 tables, is what I meant by "non trivial" ;-) "Sites like this aren't exactly heavy on the SQL." Invalid refutation, I said "if you used an RDBMS and ". That "and" was a boolean and. I never said you had to use an RDBMS to make a useful website. But if I was hiring for an RDBMS backed website , and you claimed to have used an RDBMS "for years" you'd better damned well know the basics. No "I don't know how to do a join across two tables because I did it in the application layer" doesn't cut it. That is a really stupid explanation of your ignorance and blows a big hole in your supposed "experience" with RDBMS. "You don't have to drop below it; you can go "above" it into the application layer." Sure you don't have to drop below the ORM. But you'd better know how to and when to . I wouldn't trust a developer with an ORM who didn't know ultra basic SQL. And a join in an RDBMS is ultra basic - someone claiming knowledge of an RDBMS and not knowing how to do a simple join across two tables (the OP's question was aa simple join across two tables) is like someone claiming to be an expert in c and not knowing how to write a for loop (let alone use pointers). Is that possible? I guess, Is it probable? Not at all. Besides, using an ORM and doing a join in the application layer (without knowing how to do a SQL join) is ... unusual ;-). "Let's consider the case of someone with a PhD who ISN'T famous, and then you give him some kind of SQL test and he fails. "Man, what a load of bullcrap his PhD is! He can't even do a simple JOIN!"" Well if the PhD applied for a job that needs SQL he'd better know how to use SQL (or learn - it would take what, one day of reading a basic book on SQL to understand what a join is and formulate a query? If the PhD couldn't do that and claimed he had lots of experience with RDBMS and then said he didn't know how to write a join, then I'd write him off as incompetent (and possibly a liar) for this job, irrespective of his degree, sure) . " A lot of them don't write joins." as long as they can write a join after claiming to have worked with RDBMS for ages ;-) "So, once again, the danger of using any litmus test is you can end up filtering out extremely capable people who don't do X (but could obviously pick it up quickly), while passing minimally-capable people who CAN do X."' The danger of NOT using a quick and easy litmus test is that all kinds of idiots get through to your personal interview stage and you end up wasting a lot of time talking to incompetent people.

enjo 17y ago

I would fail if this was a 'live' screening. It's rare that I write SQL by hand, and remembering the syntax for a JOIN is something I pretty much always look up. I just don't do it by hand very anymore. I'm a very good developer (my track record would suggest as such), but I would fail at least one part of this test due to the simple inability to remember elementary SQL syntax. The interesting thing about this statement is that it shows one way out of potentially being asked to code on a whiteboard/over the phone. If you have a PhD' from MIT and/or have a strong track record of writing Open Source software, creating and selling a startup, build robots (and electric unicylces ) for fun etc, in other words, if you can show , well before the interview, that you are as good or better than the job demands, you are very unlikely to face the "find the longest subsequence in a string" or "write a join" type questions. But then if you could do all that why would you look for a job? That's just not true, particularly at the larger companies out there. Amazon, for instance, has a rigorous process that you can't (more or less) circumvent. It involves a lot of saying algorithms over the phone. It was one of the most challenging interviews I've done in my life. Not because of the content, but because of the method.

plinkplonk 17y ago
"That's just not true, particularly at the larger companies out there. Amazon, for instance, has a rigorous process that you can't (more or less) circumvent. " "more or less" is key. If someone at the level of PG or RTM (or Linus or Hejlsberg, say) were to apply to Amazon (or Google or Yahoo), I am sure they aren't going to be asked to code "subsequence of a string" on the phone! They'd no doubt get a good interview but i highly doubt thatthis kind of "ask trivial questions" interview would occur. The purpose of such phone interviews is to eliminate clueless people who have the knack of writing good resumes , the "all hat and no cattle" types. I was specifically responding to this sentence "PG, RTM, and TLB would probably fail your test". I doubt that somehow!
- vax_11 17y ago
  > I was specifically responding to this sentence "PG, RTM, and TLB would probably fail your test". I doubt that somehow! But you'd be wrong.

jasonkester 17y ago

"I used MySQL for years, long ago, and never wrote a join." Wow. Note to self: start asking candidates to write SQL in interviews. It had just never occurred to me that people who spend their entire lives talking to databases wouldn't know how to talk to them directly. And really, you can get pretty much any piece of information out of a database using just four keywords. It's the least memorization of any language in history. SELECT, FROM, WHERE, and for extra credit, LIKE. That's it. That'll get you any non-aggregate dataset you could want, joined or otherwise. Learn IN and GROUP BY and you've got everything else you'll ever need for reporting. It's just the simplest language ever.

vax_11 17y ago
> It had just never occurred to me that people who spend their entire lives talking to databases wouldn't know how to talk to them directly. You're begging the question. Most people who use databases don't "spend their entire lives" talking to them. Of course I've talked to databases "directly", tuned them, "alter"ed them, indexed them, replicated them, and so forth, but just happened to use logic at the application level instead of the SQL level for JOIN functionality.
- james2vegas 17y ago
  Ok so hopefully the places where you used to work hired someone that wouldn't write horribly inefficient client-side code to join two tables together when its a SQL RDBMS, and sped up those applications|sites considerably.
Flemlord 17y ago
> Note to self: start asking candidates to write SQL in interviews. Heh. Quite a few people (~20%) take the attitude of the parent poster, saying they're not solid on SQL since they've been using ORMs for a while. So I ask them to write the same select in LINQ or their ORM language of choice. Not a single one has been able to do it.

vax_11 17y ago

> if you used an RDBMS in a non trivial app Depends on what you mean by "trivial". You can use a database for most of the things most websites use them for without ever using a JOIN. It just takes application logic instead of SQL. Sites like this aren't exactly heavy on the SQL. This site doesn't even use SQL. Something like Reddit or Slashdot would, but still wouldn't need JOINs. > I've never yet seen a non trivial RDBMS based app where the existence of an ORM absolved developers from having a good grasp of SQL when they needed to drop below the abstraction layer provided by the ORM. You don't have to drop below it; you can go "above" it into the application layer. > If you have a PhD' from MIT and/or have a strong track record of writing Open Source software, creating and selling a startup, build robots (and electric unicylces ) for fun etc, [...] But then if you could do all that why would you look for a job? Let's consider the case of someone with a PhD who ISN'T famous, and then you give him some kind of SQL test and he fails. "Man, what a load of bullcrap his PhD is! He can't even do a simple JOIN!" There are a lot of people who aren't "PhD millionaires" or famous open-source magnates and yet are vastly capable. A lot of them don't write joins. And a lot of people who CAN write joins can't do a bunch of other stuff. You know what else PG doesn't do? CSS. He runs a website but doesn't use CSS or SQL. So, once again, the danger of using any litmus test is you can end up filtering out extremely capable people who don't do X (but could obviously pick it up quickly), while passing minimally-capable people who CAN do X.

plinkplonk 17y ago
"Depends on what you mean by "trivial". " Anything that has more than say, 2 tables, is what I meant by "non trivial" ;-) "Sites like this aren't exactly heavy on the SQL." Invalid refutation, I said "if you used an RDBMS and ". That "and" was a boolean and. I never said you had to use an RDBMS to make a useful website. But if I was hiring for an RDBMS backed website , and you claimed to have used an RDBMS "for years" you'd better damned well know the basics. No "I don't know how to do a join across two tables because I did it in the application layer" doesn't cut it. That is a really stupid explanation of your ignorance and blows a big hole in your supposed "experience" with RDBMS. "You don't have to drop below it; you can go "above" it into the application layer." Sure you don't have to drop below the ORM. But you'd better know how to and when to . I wouldn't trust a developer with an ORM who didn't know ultra basic SQL. And a join in an RDBMS is ultra basic - someone claiming knowledge of an RDBMS and not knowing how to do a simple join across two tables (the OP's question was aa simple join across two tables) is like someone claiming to be an expert in c and not knowing how to write a for loop (let alone use pointers). Is that possible? I guess, Is it probable? Not at all. Besides, using an ORM and doing a join in the application layer (without knowing how to do a SQL join) is ... unusual ;-). "Let's consider the case of someone with a PhD who ISN'T famous, and then you give him some kind of SQL test and he fails. "Man, what a load of bullcrap his PhD is! He can't even do a simple JOIN!"" Well if the PhD applied for a job that needs SQL he'd better know how to use SQL (or learn - it would take what, one day of reading a basic book on SQL to understand what a join is and formulate a query? If the PhD couldn't do that and claimed he had lots of experience with RDBMS and then said he didn't know how to write a join, then I'd write him off as incompetent (and possibly a liar) for this job, irrespective of his degree, sure) . " A lot of them don't write joins." as long as they can write a join after claiming to have worked with RDBMS for ages ;-) "So, once again, the danger of using any litmus test is you can end up filtering out extremely capable people who don't do X (but could obviously pick it up quickly), while passing minimally-capable people who CAN do X."' The danger of NOT using a quick and easy litmus test is that all kinds of idiots get through to your personal interview stage and you end up wasting a lot of time talking to incompetent people.