14 ms·

Potential Employee Perspective: they can't be serious!!! A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the mode

Potential Employee Perspective: they can't be serious!!! A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one. Maybe employers should stop trying to find the non-existing 'developer rock-star' and people would stop lying. The funny thing is that even the developers themselves start to behave like that when they are on the other end of the hiring (Been there, done that). "never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN. Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything. The crap you can get into and stuck in it when working with legacy stuff is crazy. And you can end up working with something for years without having the liberty to experience and grow. That's the sad truth about software development. Well one of them at least.

jsudhams 10y ago
Agree with you MrLefHand, But would it not be responsibility of sql programmer to keep himself update? even if it is not possible in company. Like we never get to touch AD in any company because most of them already have it setup but we still go and test in VM with eval editions and such?
- MrLeftHand 10y ago
  Yes you can and you should. Sometimes it's hard to get ahead to learn stuff by yourself when you have a mind numbing job to go to. But then maybe the person doesn't belong in to the world of software development. Another problem is, when you learn something outside of work it wont be enough, because they want "commercial" experience. Like when they are hiring mobile developers and ask: "do you have any successful apps on the store?" If I would have any successful apps on the store would I be here doing this interview with you?
- lmm 10y ago
  Sometimes you don't know what you don't know. I was completely torn apart the first time I was interviewed for a Scala position, because the guy didn't believe I could possibly have spent three months doing Scala professionally and didn't know basic List methods like fold (we'd been avoiding using Scala collections because we knew the migration was coming, and had just been writing Scala with the Java collections).
  - jghn 10y ago
    My first scala job was with a group that didn't like to use a lot of the more FP-like constructs such as folding. So I also didn't have experience with that after three months. You could argue that meant I wasn't really using scala but I wasn't totally clueless.
taneq 10y ago
I think the laundry list interview happens most when you're hiring to replace someone. My last job is having that issue, we were an R&D team so we learned on the job. They're having an impossible time replacing any of us because to combine that specific skill set you basically have to have been on that team (or its twin) for a couple of years. What they should be looking for is just someone with good basic skills who learns fast. Of course, they won't do that.
- mlvljr 10y ago
  Because they are themselves scared to not follow this (ill) pattern, in some cases, I suspect :) Someone has to have guts in this relationship, and if both sides are shy, things drive themselves to the sorrow state we're discussing.
- MrLeftHand 10y ago
  100% agreed. Most of the time the hiring is about replacement, or expansion. And in expansion I mean "the current team is not enough to handle all the cr*p so we have to bring in people, preferably with the same skill set as the others, so we don't have to bother with getting them up to speed" not the "we need more people because we just started something new and we need fresh blood in the system".
- doingmyting 10y ago
  Damn, you hit the nail on the head! It's like after a divorce looking for someone exactly like your ex-wife down to the very minute detail.
arethuza 10y ago
5 years of SQL experience and no idea of what a join is? Isn't that like saying 5 years of C/Java/C#/... experience and not knowing what assignment is?
- MrLeftHand 10y ago
  I don't thinks so. You don't have to use join, but you might end up with loads of queries instead of having just one, but the end result will be the same set of data.
  - arethuza 10y ago
    If the data you are querying is spread across multiple tables (and in "enterprise" environments databases with hundreds, thousands, tens of thousands of tables or more are fairly common) then you have to do a join somewhere - in SQL, in your application or even manually. Given that doing the join in SQL is by far the most common scenario not being aware of it is a bit odd!
  - pjmorris 10y ago
    Arguably that's one year of SQL experience repeated five times.
    - dllthomas 10y ago
      Or one week of SQL experience repeated 250 times...
      - pedrosorio 10y ago
        One day?
        dllthomas 10y ago
        Arguably.
    - sotojuan 10y ago
yeowMeng 10y ago
> Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything. You are not allowed to change anything and commit it :) But it's amazing how much cruft you can dig out by say, re-writting the build system so that everything links dynamically and then running an address sanitizer build in dev env.
kragen 10y ago
My first tech job assignment required SQL. I didn't know it, didn't claim I knew it, got the job, read the O'Reilly book on SQL on the plane on my way to California. I learned about joins (although maybe not the JOIN keyword). This was about the time MySQL came out, and years before Postgres added SQL support, so at the time your rather pathetic argument might have had merit, because there wasn't actually a way to get hands-on experience with SQL without a pricey license for proprietary software. I still don't think it's reasonable to claim that you have "SQL experience" if you haven't touched joins. That's like saying you have JavaScript experience but don't know how to define a function. Now, though, Skype and every browser embed SQLite. If you don't know enough SQL to do a join, it's because you lack intellectual curiosity. Don't blame your employer. When I was hiring people, I wanted people who could do the job, not people who would lie that they could, then blame my company.
- st3v3r 10y ago
  "If you don't know enough SQL to do a join, it's because you lack intellectual curiosity. " Or other things have grabbed your interest. Are you saying that one lacks "intellectual curiosity" because they have had other priorities than learning this one specific technology?
  - kragen 10y ago
    If you're a programmer of any kind, sooner or later, you need to understand the relational data model and normalization. They're useful to you in every field of programming; they're one of those magic technologies that can frequently turn 200 lines of code into 10 lines, converting a day-long task into something so simple you can do it off-the-cuff. SQL is by far the most accessible way to use the relational data model, whatever the merits of Tutorial D and Prolog, and once you start normalizing your data, you need joins. If we were talking about cuckoo hashing, 386 assembly, or FIR filter design, I would agree that it's "one specific technology" that someone could easily pass over with little loss in many programming fields. But not knowing how to do a join is more like not knowing how to open a file or use floating-point math: it's a crippling deficiency in your skills as a programmer, one that will slow you down in a wide variety of tasks.
mbesto 10y ago
Both responses sound oddly like dating.
- drdeadringer 10y ago
  Because that is what the process of hiring is. Dating and interviews go both ways. "I don't want to hire you" is a valid as "I don't want to work for you".
gregmac 10y ago
> A lot of times a job spec contains a minimum of 10-15 skill you need to know. This can also happen if they are just bad at writing job requirements. Remember, it is typically programmers (or their managers) writing these things, and sometimes HR or a recruiter (who doesn't understand any technical details) "cleaning" it up. They may just mean "Here are the skills we need, we want to hire someone that knows some of these, and is able to learn the rest fairly quickly". Of course, they could also have someone specific in mind (but are required to post the job anyway), and in some cases may be delusional and really think they can find someone with all those skills.
llamataboot 10y ago
Look, I think most companies put too many skills on their wishlist. And if, in fact, you weren't actually going to be using SQL too much, but using ActiveRecord all the time, maybe it is acceptable to say "Well, I actually don't know how to do that in SQL, but here's how I'd do it in ActiveRecord (do it correctly) and here's how you examine the SQL that ActiveRecord is generating, and I'm happy to study SQL and the guts of ActiveRecord if we need to do a lot of complex queries..." and okay, you made your case. But if the job requires SQL experience and you don't know how to do a basic join? Sorry, not gonna be a good fit. I mean, employers need to ask for some specific skills!
qaq 10y ago
Y some of them are really cool like VB, Hadoop and Spark
hanginghyena 10y ago
So respond to that job spec with a resume which clearly highlights the 3-4 things you actually did master, with multiple specific project examples and real roles/jobs. You may be pleasantly surprised. Speaking for myself, I will gleefully hop over piles of candidates with a 1/4 page of alphabet soup on their CV trying to talk with the candidate who hammers Python, PHP, Javascript (etc) across a 5+ years of different projects. Even if I'm hiring for a slightly different technology, because I can be confident they actually know the trade. Multiple skill-sets do add value if they are related and easily combined to deliver a larger solution. Eg. HTML + CSS + Javascript = Front End Web Dev + Python + SQL = Full Stack Web Developer. So I can staff that person in a larger role. The spew of semi-related and adjacent buzzwords doesn't really help me feel comfortable with a candidate. And if I start asking you about them and learn all you did was read about them online (or used it once for a class), the rest of your resume goes into the danger zone real quick. "I mastered X, Y, and Z and used them together to build <pure awesomeness>" will get you further than you think. Even if the job doesn't require X, Y, and Z....
- cmdrfred 10y ago
  That is my plan. Working on an anonymous web based end to end encrypted chat system with that exact stack. Then I'm going to write an android app to accompany it. I'll see if I can get my foot in the door.
golergka 10y ago
> "never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN. Most of my experience with SQL comes from being a game designer with access to analytics database - so, not exactly a lot. But how the hell would you not touch join even a single time while working with SQL for 5 years?!
- bobwaycott 10y ago
  Two ways I can think of off the top of my head: 1. Total reliance on ORMs, and never actually touching SQL (or not in 5 years since you started using ORMs) 2. Not building complex relational schemas with related items that you use SQL to pull in results of combined data that follows those relationships. I'd wager #1 is the more common case.
  - dagw 10y ago
    Or they're just using a bunch of SELECT * WHERE X queries and then filtering the results in their favorite programming language
    - bobwaycott 10y ago
      That, too.
    - Thriptic 10y ago
      This. With smaller amounts of data it's not even a big deal. Just pull everything into python or R and subset in there.
  - golergka 10y ago
    But in #1 you're not working with SQL, you're working with a layer above it. And wouldn't even the most basic data, properly normalized, require joins? I mean - learning about database normalization is one of the first things you're supposed to do when you work with relational databases, right?
scottlamb 10y ago
> A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one. Most job listings I've seen don't really have that many hard requirements. They may mention technologies you'll be working with or things they'd like to see, but that shouldn't stop you from applying if you don't know them all. Take this with a grain of salt because I've never done resume filtering, but when I interview someone, I look at their resume and ask them about the things on it that I also know. (And I'll decline the interview if there's no overlap.) So for my stage in the process, the optimal strategy is to put the things you're best at on your resume, even if they're not listed on the job description. You get to pick what we talk about. For the most part I'll assume that if you've mastered those things, you can master the things we're looking for too. (Subject to some constraints: if there are four interviews, they shouldn't all be about the same things. So each interviewer might be assigned a broad area to discuss or have to write down their questions/area before the next interview starts so the next interviewer can pick something else.) > "never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN. I look for a core concept or two for each area/technology and ask about that: * For SQL, that definitely means join. If you don't know how to join two relations, you should learn or take SQL off your resume. * Likewise, for C/C++ I want to know that you understand memory safety. Who owns memory across an API boundary. * For algorithms / data structures (a likely main topic if you're a recent CS grad), that for a simple problem you can use the best basic data structure (array / list / heap / balanced tree / hash table) and tell me the time and memory complexity in Big-Oh notation. > Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything. That's not the sort of job I do or interview people for. I have no idea what interviews for that kind of job are like. But if you're not doing sophisticated SQL or algorithms, surely you're doing something with your time? What is it? Can you emphasize it and sell it? > The crap you can get into and stuck in it when working with legacy stuff is crazy. And you can end up working with something for years without having the liberty to experience and grow. That's not a problem with interviews; it's a feature. Why should someone want to hire you if you haven't been growing? Or if they do, why should they want to pay you as if you were actually gaining experience for those years? I'd be looking for a better job the whole time.
- hanginghyena 10y ago

jsudhams 10y ago

Agree with you MrLefHand, But would it not be responsibility of sql programmer to keep himself update? even if it is not possible in company. Like we never get to touch AD in any company because most of them already have it setup but we still go and test in VM with eval editions and such?

MrLeftHand 10y ago
Yes you can and you should. Sometimes it's hard to get ahead to learn stuff by yourself when you have a mind numbing job to go to. But then maybe the person doesn't belong in to the world of software development. Another problem is, when you learn something outside of work it wont be enough, because they want "commercial" experience. Like when they are hiring mobile developers and ask: "do you have any successful apps on the store?" If I would have any successful apps on the store would I be here doing this interview with you?
lmm 10y ago
Sometimes you don't know what you don't know. I was completely torn apart the first time I was interviewed for a Scala position, because the guy didn't believe I could possibly have spent three months doing Scala professionally and didn't know basic List methods like fold (we'd been avoiding using Scala collections because we knew the migration was coming, and had just been writing Scala with the Java collections).
- jghn 10y ago
  My first scala job was with a group that didn't like to use a lot of the more FP-like constructs such as folding. So I also didn't have experience with that after three months. You could argue that meant I wasn't really using scala but I wasn't totally clueless.

taneq 10y ago

I think the laundry list interview happens most when you're hiring to replace someone. My last job is having that issue, we were an R&D team so we learned on the job. They're having an impossible time replacing any of us because to combine that specific skill set you basically have to have been on that team (or its twin) for a couple of years. What they should be looking for is just someone with good basic skills who learns fast. Of course, they won't do that.

mlvljr 10y ago
Because they are themselves scared to not follow this (ill) pattern, in some cases, I suspect :) Someone has to have guts in this relationship, and if both sides are shy, things drive themselves to the sorrow state we're discussing.
MrLeftHand 10y ago
100% agreed. Most of the time the hiring is about replacement, or expansion. And in expansion I mean "the current team is not enough to handle all the cr*p so we have to bring in people, preferably with the same skill set as the others, so we don't have to bother with getting them up to speed" not the "we need more people because we just started something new and we need fresh blood in the system".
doingmyting 10y ago
Damn, you hit the nail on the head! It's like after a divorce looking for someone exactly like your ex-wife down to the very minute detail.

arethuza 10y ago

5 years of SQL experience and no idea of what a join is? Isn't that like saying 5 years of C/Java/C#/... experience and not knowing what assignment is?

MrLeftHand 10y ago
I don't thinks so. You don't have to use join, but you might end up with loads of queries instead of having just one, but the end result will be the same set of data.
- arethuza 10y ago
  If the data you are querying is spread across multiple tables (and in "enterprise" environments databases with hundreds, thousands, tens of thousands of tables or more are fairly common) then you have to do a join somewhere - in SQL, in your application or even manually. Given that doing the join in SQL is by far the most common scenario not being aware of it is a bit odd!
- pjmorris 10y ago
  Arguably that's one year of SQL experience repeated five times.
  - dllthomas 10y ago
    Or one week of SQL experience repeated 250 times...
    - pedrosorio 10y ago
      One day?
      - dllthomas 10y ago
        Arguably.
  - sotojuan 10y ago

yeowMeng 10y ago

> Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything. You are not allowed to change anything and commit it :) But it's amazing how much cruft you can dig out by say, re-writting the build system so that everything links dynamically and then running an address sanitizer build in dev env.

kragen 10y ago

My first tech job assignment required SQL. I didn't know it, didn't claim I knew it, got the job, read the O'Reilly book on SQL on the plane on my way to California. I learned about joins (although maybe not the JOIN keyword). This was about the time MySQL came out, and years before Postgres added SQL support, so at the time your rather pathetic argument might have had merit, because there wasn't actually a way to get hands-on experience with SQL without a pricey license for proprietary software. I still don't think it's reasonable to claim that you have "SQL experience" if you haven't touched joins. That's like saying you have JavaScript experience but don't know how to define a function. Now, though, Skype and every browser embed SQLite. If you don't know enough SQL to do a join, it's because you lack intellectual curiosity. Don't blame your employer. When I was hiring people, I wanted people who could do the job, not people who would lie that they could, then blame my company.

st3v3r 10y ago
"If you don't know enough SQL to do a join, it's because you lack intellectual curiosity. " Or other things have grabbed your interest. Are you saying that one lacks "intellectual curiosity" because they have had other priorities than learning this one specific technology?
- kragen 10y ago
  If you're a programmer of any kind, sooner or later, you need to understand the relational data model and normalization. They're useful to you in every field of programming; they're one of those magic technologies that can frequently turn 200 lines of code into 10 lines, converting a day-long task into something so simple you can do it off-the-cuff. SQL is by far the most accessible way to use the relational data model, whatever the merits of Tutorial D and Prolog, and once you start normalizing your data, you need joins. If we were talking about cuckoo hashing, 386 assembly, or FIR filter design, I would agree that it's "one specific technology" that someone could easily pass over with little loss in many programming fields. But not knowing how to do a join is more like not knowing how to open a file or use floating-point math: it's a crippling deficiency in your skills as a programmer, one that will slow you down in a wide variety of tasks.

mbesto 10y ago

Both responses sound oddly like dating.

drdeadringer 10y ago
Because that is what the process of hiring is. Dating and interviews go both ways. "I don't want to hire you" is a valid as "I don't want to work for you".

gregmac 10y ago

> A lot of times a job spec contains a minimum of 10-15 skill you need to know. This can also happen if they are just bad at writing job requirements. Remember, it is typically programmers (or their managers) writing these things, and sometimes HR or a recruiter (who doesn't understand any technical details) "cleaning" it up. They may just mean "Here are the skills we need, we want to hire someone that knows some of these, and is able to learn the rest fairly quickly". Of course, they could also have someone specific in mind (but are required to post the job anyway), and in some cases may be delusional and really think they can find someone with all those skills.

llamataboot 10y ago

Look, I think most companies put too many skills on their wishlist. And if, in fact, you weren't actually going to be using SQL too much, but using ActiveRecord all the time, maybe it is acceptable to say "Well, I actually don't know how to do that in SQL, but here's how I'd do it in ActiveRecord (do it correctly) and here's how you examine the SQL that ActiveRecord is generating, and I'm happy to study SQL and the guts of ActiveRecord if we need to do a lot of complex queries..." and okay, you made your case. But if the job requires SQL experience and you don't know how to do a basic join? Sorry, not gonna be a good fit. I mean, employers need to ask for some specific skills!

qaq 10y ago

Y some of them are really cool like VB, Hadoop and Spark

hanginghyena 10y ago

So respond to that job spec with a resume which clearly highlights the 3-4 things you actually did master, with multiple specific project examples and real roles/jobs. You may be pleasantly surprised. Speaking for myself, I will gleefully hop over piles of candidates with a 1/4 page of alphabet soup on their CV trying to talk with the candidate who hammers Python, PHP, Javascript (etc) across a 5+ years of different projects. Even if I'm hiring for a slightly different technology, because I can be confident they actually know the trade. Multiple skill-sets do add value if they are related and easily combined to deliver a larger solution. Eg. HTML + CSS + Javascript = Front End Web Dev + Python + SQL = Full Stack Web Developer. So I can staff that person in a larger role. The spew of semi-related and adjacent buzzwords doesn't really help me feel comfortable with a candidate. And if I start asking you about them and learn all you did was read about them online (or used it once for a class), the rest of your resume goes into the danger zone real quick. "I mastered X, Y, and Z and used them together to build <pure awesomeness>" will get you further than you think. Even if the job doesn't require X, Y, and Z....

cmdrfred 10y ago
That is my plan. Working on an anonymous web based end to end encrypted chat system with that exact stack. Then I'm going to write an android app to accompany it. I'll see if I can get my foot in the door.

golergka 10y ago

> "never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN. Most of my experience with SQL comes from being a game designer with access to analytics database - so, not exactly a lot. But how the hell would you not touch join even a single time while working with SQL for 5 years?!

bobwaycott 10y ago
Two ways I can think of off the top of my head: 1. Total reliance on ORMs, and never actually touching SQL (or not in 5 years since you started using ORMs) 2. Not building complex relational schemas with related items that you use SQL to pull in results of combined data that follows those relationships. I'd wager #1 is the more common case.
- dagw 10y ago
  Or they're just using a bunch of SELECT * WHERE X queries and then filtering the results in their favorite programming language
  - bobwaycott 10y ago
    That, too.
  - Thriptic 10y ago
    This. With smaller amounts of data it's not even a big deal. Just pull everything into python or R and subset in there.
- golergka 10y ago
  But in #1 you're not working with SQL, you're working with a layer above it. And wouldn't even the most basic data, properly normalized, require joins? I mean - learning about database normalization is one of the first things you're supposed to do when you work with relational databases, right?

scottlamb 10y ago

> A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one. Most job listings I've seen don't really have that many hard requirements. They may mention technologies you'll be working with or things they'd like to see, but that shouldn't stop you from applying if you don't know them all. Take this with a grain of salt because I've never done resume filtering, but when I interview someone, I look at their resume and ask them about the things on it that I also know. (And I'll decline the interview if there's no overlap.) So for my stage in the process, the optimal strategy is to put the things you're best at on your resume, even if they're not listed on the job description. You get to pick what we talk about. For the most part I'll assume that if you've mastered those things, you can master the things we're looking for too. (Subject to some constraints: if there are four interviews, they shouldn't all be about the same things. So each interviewer might be assigned a broad area to discuss or have to write down their questions/area before the next interview starts so the next interviewer can pick something else.) > "never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN. I look for a core concept or two for each area/technology and ask about that: * For SQL, that definitely means join. If you don't know how to join two relations, you should learn or take SQL off your resume. * Likewise, for C/C++ I want to know that you understand memory safety. Who owns memory across an API boundary. * For algorithms / data structures (a likely main topic if you're a recent CS grad), that for a simple problem you can use the best basic data structure (array / list / heap / balanced tree / hash table) and tell me the time and memory complexity in Big-Oh notation. > Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything. That's not the sort of job I do or interview people for. I have no idea what interviews for that kind of job are like. But if you're not doing sophisticated SQL or algorithms, surely you're doing something with your time? What is it? Can you emphasize it and sell it? > The crap you can get into and stuck in it when working with legacy stuff is crazy. And you can end up working with something for years without having the liberty to experience and grow. That's not a problem with interviews; it's a feature. Why should someone want to hire you if you haven't been growing? Or if they do, why should they want to pay you as if you were actually gaining experience for those years? I'd be looking for a better job the whole time.

hanginghyena 10y ago