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.

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

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

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.

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?

After interviewing thousands of candidates over the years, I say anything is possible. One candidate I recall was 24+ years of development experience mostly consulting in firmware. He graduated from a top school and was referred by our VP of ASIC engineering. Yet he struggled at the most basic C pointer question. He tried everything in the interview to prevent us from asking any coding questions.

Oh my! How can you work in firmware and not know the basics of C pointers? Firmware is mostly C!

I met a professional, working Rails dev who didn't know how to expose a class's instance variables for read access in Ruby. (i.e. write getters)

(Not an interview context though; it was a hack night where I was learning ruby and didn't know the right terms to use to look up that question from the docs.)

Just out of curiosity, did you phrase the question "expose a class's instance variables for read access," or "write a getter?" I see it as the difference between academic phrasing and colloquial.

I phrased the question in many different ways and verified that he understood that I meant, "how do I get the value of @foo from an object of a class that has @foo?" The answer he gave did not hinge on the distinction, and ended up being the ol'

    def foo
      @foo
    end

Maybe 5 years of Java without using inheritance?

It's possible but feels like you haven't gone the distance.

... or you are Rich Hickey :)

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.

But if you have loads of queries and do the "join" in your application code, you will suffer serious performance problems with any reasonable data set. If a programmer is going to be writing SQL for anything larger than a toy problem, they have to know how to use JOIN.

Arguably that's one year of SQL experience repeated five times.

Or one week of SQL experience repeated 250 times...

One day?

Arguably.

Yep. Believe it or not depending on the team/manager/programmer that happens very often.

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!

Or you can use where a.id = b.id and you cover 90% of joins (inner join). I only once needed an outer join in the last 10 years all other cases and here inner joins. And I prefer the where syntax, it's cleaner for me than the join one.

THIS.

Yes, there are SQL statements without Joins. No, we don't usually run them in the reporting organization....

I have 3 years of SQL and while I do know what a join is, I doubt I could write a syntactically correct one that does what it's supposed to do, on a whiteboard. I'd need some test data and access to google, and at least three or four attempts.

Reason is, I work with a CMS that handles 99% of my queries for me. It would be monstrously inefficient for me to go around handwriting sql all the time. Any time it happens is by definition an extreme circumstance, so that's how I do it when it happens - with test data, google, and several attempts.

I'm pretty sure that would be reasonable for most jobs, but I wouldn't pass the tech screen if they wanted me to just freestyle it.

That's fine, but you have 3 years of experience with a CMS. SQL is the Structured Query Language used to make queries, so if you're not writing that, then you aren't working with SQL.

I've been driving cars for twenty years, but it doesn't mean I have two decades of experience with fuel injectors.

Your example makes your point very well. You are totally right.

So you have three years of experience using tool which does the work of generating SQL for you. If you can't write a proper JOIN from memory then you shouldn't be putting "three years of SQL experience" on your CV.

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!

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?

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?

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

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.

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

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

> "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?!

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.

Or they're just using a bunch of SELECT * WHERE X queries and then filtering the results in their favorite programming language

This. With smaller amounts of data it's not even a big deal. Just pull everything into python or R and subset in there.

That, too.

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?

Both responses sound oddly like dating.

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

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.

> This was about the time MySQL came out, and years before Postgres added SQL support

Didn't those happen nearly at the same time? Postgres95 (which PostgreSQL started from) had support for some subset of SQL (including inner joins): https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f... outer joins were added a bit later: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...

I didn't realize Postgres already had SQL support in 1994! I didn't try to use it around that time; msql was a thing for a while, and then people moved to the protocol-compatible MySQL. I was using INFORMIX in that job (1996–7) and it wasn't for several more years that e.g. Slashdot switched to SQL backends.

So why didn't people use SQL in Postgres95? The licensing was fine. My best guess is that the SQL support wasn't yet good enough to be useful. The database as such (transactions, data types, persistence) was already pretty solid, as I understand it.

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

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.

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

There's actually significant learning value in time spent figuring out legacy systems and linking them together. Doing ad-hoc reporting is the IT equivalent of being a short order cook.

Do it long enough, and you learn how to make almost anything from nothing.

And that should be considered an employable skill....

I agree. Deciphering legacy systems, integrating them, debugging them, and finding minimal safe fixes involves a whole set of legitimate, resume-worthy skills.

> Doing ad-hoc reporting is the IT equivalent of being a short order cook.

Nice analogy.

I used to do a fair amount of ad-hoc reporting on an Oracle database. I used joins (inner and outer), subselects (or self-joins), aggregates, window functions (or whatever Oracle equivalent existed at the time), etc. I'd never hire someone who said they did ad-hoc reporting with SQL but didn't know joins, and I'd be skeptical of someone who didn't know some of these other concepts.