4 ms·

Part of it may be your questions, and part may be HOW you're asking (e.g. over the phone, or putting someone on the spot). 2) Not a lot of people write SQL by

by vax_11 17y ago

Part of it may be your questions, and part may be HOW you're asking (e.g. over the phone, or putting someone on the spot). 2) Not a lot of people write SQL by hand anymore. I used MySQL for years, long ago, and never wrote a join. Then ORMs came along and handle joins automatically, so I've still never written one. So not being able to do it without looking it up doesn't really tell you anything. I've written far, far more complex things than an SQL join statement. A more pertinent issue I'd be checking for is whether user input is properly escaped to prevent SQL injection -- again, not an issue with ORMs, but an issue when building SQL query strings by hand. 1) A lot of people use languages where recursion is unusual (i.e. NOT Lisp). Even a senior developer (especially of something like PHP) might not recall this, not having actually written a recursive function for years. 3) Representing a car as an object: A lot of software people don't know hardware, so the confounding part might be recalling various attributes of cars and how they relate to each other. Also keep in mind that many introverted people get very uncomfortable when someone is waiting on them. This can make it difficult to concentrate at all. Being asked to perform on demand is normal for a musician but foreign to most programmers. On top of that, it's usually in an unfamiliar environment, such as verbally or on a whiteboard -- imagine asking a violinist to play on some lines you drew on a piece of paper. PG, RTM, and TLB would probably fail your test -- they don't use SQL, they use flat files.

jockc 17y ago
Sorry, we decided to go with another applicant. We'll keep your resume on file.
- vax_11 17y ago
  As noted, there are numerous expert programmers who couldn't do an SQL join in a live interview. Besides PG, RTM, and TLB, most or all of the Linux kernel programmers, including Linus; Pete Norvig; embedded systems programmers; and on and on. You could find a lot of people who can handle the SQL you need while screening out brilliant people who are FAR more capable, but just happen not to know item X.
plinkplonk 17y ago
"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.
mquander 17y ago
Well, if you're using ORMs to handle all your SQL needs (and they literally must be handling all your needs if you're never writing anything with a join) then I don't think that you actually have a working knowledge of SQL in any sense. There are certainly plenty of jobs which require that knowledge, and I'm not sure an employer would want someone who didn't have direct SQL language experience. To be honest, I don't understand how you manage not writing joins even if your ORM is perfect and flawless. I use the SQL prompt like an interactive debugger, writing queries to look at the internal state of my database. (I assume that the original post refers to applicants that listed "SQL" somewhere on their resume, or else he wouldn't be asking SQL syntax questions -- I hold that if you have "SQL" on your resume, you had better know how to write a join.)
- vax_11 17y ago
  > then I don't think that you actually have a working knowledge of SQL in any sense. Of course I have working knowledge of SQL, that's how I used MySQL back when we had to write things by hand. I just don't have a working knowledge of JOINs. I could look up the syntax if I needed to use it. [Looks it up] Looks easy enough. There are numerous SQL commands most users of SQL would probably need to look up. Arbitrarily deciding that having not-used X means you don't have a working knowledge is a fallacy. Someone else could arbitrarily decide the litmus test is stored procedures. MySQL didn't have those, so instead of using them we had to code at the application layer, and just happened to use application logic in places of JOINs as well. I don't even remember if MySQL had joins, or non-buggy joins, a dozen years ago. Other people would say, "it doesn't have transactions, so it's not a real database", et cetera, et cetera. You work around limitations and get used to doing things a certain way.
  - james2vegas 17y ago
    It had JOINs but a lousy, lousy optimizer, also sub-SELECTs were (are?) a problem. I can't say that having a sort-of knowledge of some (very little)of MySQL is equivalent to having a working knowledge of SQL. Most commands that SQL users would probably need to look up would be the DDL commands, not simple (yes, it really is simple) stuff like LEFT OUTER and INNER JOINs. Also while saying MySQL didn't have SPs is an (fair) indictment of MySQL, you using application logic instead of JOINs is an indictment of you and your supposed 'working SQL knowledge'
warfangle 17y ago
I don't think the violinist comparison is fair. Any violinist worth their salt has practiced sight reading to death. Absolute death. It's difficult to do, yes, but if you're playing in any sort of group situation (orchestra, etc), sight reading is extremely important. Unless you're saying "I drew some lines on this piece of paper that represent the strings on the violin; I want you to play the piece of paper like you would the instrument." In which case it's a worthless interview. Whiteboards are fairly common for code snippits and pseudocode at most of the jobs I've worked. Pieces of paper with representational lines for the strings are used as individual studies (e.g., sheet music) - not for collaboration. That's usually done in jam-format..
- vax_11 17y ago
  > Unless you're saying "I drew some lines on this piece of paper that represent the strings on the violin; I want you to play the piece of paper like you would the instrument." Yes, that's it. > In which case it's a worthless interview. I'd say the same applies to whiteboards. I have never sketched out code on a whiteboard except in an interview. Of course you can do so and become accustomed to it, just like you can finger a paper violin or piano.
planck 17y ago
"PG, RTM, and TLB would probably fail your test -- they don't use SQL, they use flat files." Well, then they likely wouldn't be a good fit for the position the OP is hiring for, since it requires using SQL, not flat files.
- vax_11 17y ago
  It would be nice to see who's upvoting this so I could add them to an IDIOTS file. Any of the above people could obviously EASILY pick up whatever SQL you happened to be using. RTM could wipe the floor with you, the OP, and everyone else on your team. If your interview process filters out people like RTM, your filtering is broken.
  - planck 17y ago
    When you're hiring for any normal development position, ability matters more than reputation. If I was interviewing someone for a job that required writing SQL and asked them to write some SQL, and they couldn't, I wouldn't hire them. What is so hard to understand about that? I'm sure that I could EASILY pick up the skills required to be a gardener, but would you hire me to tend your rose bushes based on that fact? No, and that's what this discussion is about.
philwelch 17y ago
"A lot of people use languages where recursion is unusual (i.e. NOT Lisp). Even a senior developer (especially of something like PHP) might not recall this, not having actually written a recursive function for years." There are tons of languages that support recursion. Whether or not you use it is a function of the problem, not the language. (I'm not counting tail recursion since I consider tail recursion to be a functional way of expressing iteration.) "Representing a car as an object: A lot of software people don't know hardware, so the confounding part might be recalling various attributes of cars and how they relate to each other." Well, if I was given this question in an interview, I would ask, "are we building a CAD program or a car-racing game"? CAD programs (I've never written one) would probably have a CADObject class for all drafted objects that the car parts and the car itself would inherit from, and you'd have to discuss not only what was in the car but where it was connected, so just saying that it's a composition of "engine, body, brakes, air filter, etc." would be insufficient. A car-racing game would just have a car object with a shape, performance characteristics, and be able to hold states for its physical motion at a given time, as well as being able to take messages/method calls for things like "pressing the turbo button" or "emergency brake" or "shoot a missile" (depending on the racing game). You can build an entirely sensible object model for a car and be totally wrong if you don't know what you're building it for.
- vax_11 17y ago
  > There are tons of languages that support recursion Obviously. But I don't remember ever writing a recursive function in PHP for a website.
  - philwelch 17y ago
    If writing PHP for websites is the limit of your skill set, I'm worried for you. Not a personal remark, but a comment on the interviewing process.

by vax_11 17y ago

jockc 17y ago

Sorry, we decided to go with another applicant. We'll keep your resume on file.

vax_11 17y ago
As noted, there are numerous expert programmers who couldn't do an SQL join in a live interview. Besides PG, RTM, and TLB, most or all of the Linux kernel programmers, including Linus; Pete Norvig; embedded systems programmers; and on and on. You could find a lot of people who can handle the SQL you need while screening out brilliant people who are FAR more capable, but just happen not to know item X.

plinkplonk 17y ago

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

mquander 17y ago

Well, if you're using ORMs to handle all your SQL needs (and they literally must be handling all your needs if you're never writing anything with a join) then I don't think that you actually have a working knowledge of SQL in any sense. There are certainly plenty of jobs which require that knowledge, and I'm not sure an employer would want someone who didn't have direct SQL language experience. To be honest, I don't understand how you manage not writing joins even if your ORM is perfect and flawless. I use the SQL prompt like an interactive debugger, writing queries to look at the internal state of my database. (I assume that the original post refers to applicants that listed "SQL" somewhere on their resume, or else he wouldn't be asking SQL syntax questions -- I hold that if you have "SQL" on your resume, you had better know how to write a join.)

vax_11 17y ago
> then I don't think that you actually have a working knowledge of SQL in any sense. Of course I have working knowledge of SQL, that's how I used MySQL back when we had to write things by hand. I just don't have a working knowledge of JOINs. I could look up the syntax if I needed to use it. [Looks it up] Looks easy enough. There are numerous SQL commands most users of SQL would probably need to look up. Arbitrarily deciding that having not-used X means you don't have a working knowledge is a fallacy. Someone else could arbitrarily decide the litmus test is stored procedures. MySQL didn't have those, so instead of using them we had to code at the application layer, and just happened to use application logic in places of JOINs as well. I don't even remember if MySQL had joins, or non-buggy joins, a dozen years ago. Other people would say, "it doesn't have transactions, so it's not a real database", et cetera, et cetera. You work around limitations and get used to doing things a certain way.
- james2vegas 17y ago
  It had JOINs but a lousy, lousy optimizer, also sub-SELECTs were (are?) a problem. I can't say that having a sort-of knowledge of some (very little)of MySQL is equivalent to having a working knowledge of SQL. Most commands that SQL users would probably need to look up would be the DDL commands, not simple (yes, it really is simple) stuff like LEFT OUTER and INNER JOINs. Also while saying MySQL didn't have SPs is an (fair) indictment of MySQL, you using application logic instead of JOINs is an indictment of you and your supposed 'working SQL knowledge'

warfangle 17y ago

I don't think the violinist comparison is fair. Any violinist worth their salt has practiced sight reading to death. Absolute death. It's difficult to do, yes, but if you're playing in any sort of group situation (orchestra, etc), sight reading is extremely important. Unless you're saying "I drew some lines on this piece of paper that represent the strings on the violin; I want you to play the piece of paper like you would the instrument." In which case it's a worthless interview. Whiteboards are fairly common for code snippits and pseudocode at most of the jobs I've worked. Pieces of paper with representational lines for the strings are used as individual studies (e.g., sheet music) - not for collaboration. That's usually done in jam-format..

vax_11 17y ago
> Unless you're saying "I drew some lines on this piece of paper that represent the strings on the violin; I want you to play the piece of paper like you would the instrument." Yes, that's it. > In which case it's a worthless interview. I'd say the same applies to whiteboards. I have never sketched out code on a whiteboard except in an interview. Of course you can do so and become accustomed to it, just like you can finger a paper violin or piano.

planck 17y ago

"PG, RTM, and TLB would probably fail your test -- they don't use SQL, they use flat files." Well, then they likely wouldn't be a good fit for the position the OP is hiring for, since it requires using SQL, not flat files.

vax_11 17y ago
It would be nice to see who's upvoting this so I could add them to an IDIOTS file. Any of the above people could obviously EASILY pick up whatever SQL you happened to be using. RTM could wipe the floor with you, the OP, and everyone else on your team. If your interview process filters out people like RTM, your filtering is broken.
- planck 17y ago
  When you're hiring for any normal development position, ability matters more than reputation. If I was interviewing someone for a job that required writing SQL and asked them to write some SQL, and they couldn't, I wouldn't hire them. What is so hard to understand about that? I'm sure that I could EASILY pick up the skills required to be a gardener, but would you hire me to tend your rose bushes based on that fact? No, and that's what this discussion is about.

philwelch 17y ago

"A lot of people use languages where recursion is unusual (i.e. NOT Lisp). Even a senior developer (especially of something like PHP) might not recall this, not having actually written a recursive function for years." There are tons of languages that support recursion. Whether or not you use it is a function of the problem, not the language. (I'm not counting tail recursion since I consider tail recursion to be a functional way of expressing iteration.) "Representing a car as an object: A lot of software people don't know hardware, so the confounding part might be recalling various attributes of cars and how they relate to each other." Well, if I was given this question in an interview, I would ask, "are we building a CAD program or a car-racing game"? CAD programs (I've never written one) would probably have a CADObject class for all drafted objects that the car parts and the car itself would inherit from, and you'd have to discuss not only what was in the car but where it was connected, so just saying that it's a composition of "engine, body, brakes, air filter, etc." would be insufficient. A car-racing game would just have a car object with a shape, performance characteristics, and be able to hold states for its physical motion at a given time, as well as being able to take messages/method calls for things like "pressing the turbo button" or "emergency brake" or "shoot a missile" (depending on the racing game). You can build an entirely sensible object model for a car and be totally wrong if you don't know what you're building it for.

vax_11 17y ago
> There are tons of languages that support recursion Obviously. But I don't remember ever writing a recursive function in PHP for a website.
- philwelch 17y ago
  If writing PHP for websites is the limit of your skill set, I'm worried for you. Not a personal remark, but a comment on the interviewing process.