13

I'm currently applying for a job and the job description states that "Practical SQL knowledge would be a plus". I do have a lot practical SQL knowledge, even though I haven't used it in quite a while. In 2010-2013, I was an apprentice as a business software developer in the IT department of a large non-IT company, and this job was mainly about building database applications, so very SQL heavy.

10 years is quite some time, especially in this industry. Does it make sense to include this item on my resume or should I focus on more recent (yet not less relevant) work experience considering that my resume is already quite stuffed?

2
  • 2
    If you include it, be prepared to answer questions about it, ideally with something better than "I don't remember, but it will come back to me".
    – Bobson
    Jan 22 at 10:09
  • Germany is special, here companies have a black curtain in their eye for things 5 years ago.
    – Gray Sheep
    Feb 9 at 8:14

1 Answer 1

44

You should include it, it's directly relevant.

SQL hasn't changed that much in 10 years either. Practical experience like yours just needs a brush up to be up and productive.

17
  • 6
    SQL is one thing I grudgingly have to concede that they got really right all that time ago! Never goes out of style, no SQL 99 or whatever. It just works. Jan 20 at 14:01
  • 15
    @HappyIdiot SQL, the one thing that caused more security issues than probably anything else "they got really right"? Explicit parameterization is a 'hack' on top of SQL to make it safe, not a core part of SQL. Having applications write 'code' was a bad idea from start to finish. They got SQL right as a thing for humans to write, but it was a big mistake to use it as the 'API' for databases. It not going 'out of style' is more a reflection on human nature than anything else. (Easy to start with, but increasingly problematic as complexity increases). (cont.) Jan 20 at 15:16
  • 5
    (cont.) and not even talking about the mistake that joins were. Specifically how the output is forced into a single table... which once again makes sense for direct human consumption on a display, but makes absolutely no sense at all when an application consumes the output. </rant> (Didn't realize I was so passionate about that... especially as I have not found a single query solution that feels 'close to perfect' having tried and used many) Jan 20 at 15:19
  • 8
    @DavidMulder the security issues are not in SQL per se, but in not using prepared statements. The security issues aren't relevant to the question or the answer, either. (I don't think HappyIdiot's comment is completely correct either, but it's off-topic as well so nothing of this all belongs here.)
    – toolforger
    Jan 20 at 16:22
  • 7
    @quarague There absolutely is an inherent security problem in SQL in itself and that is the mixing of code and data. There is a reason that virtually nobody writes SQL statements by hand but uses some abstraction to avoid that problem. There being no clear separation is not set in stone and you can absolutely have a standard that clearly separates those two which would avoid those potential security issues.
    – Voo
    Jan 20 at 22:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .