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.

What they should be looking for is just someone with good basic skills who learns fast. Of course, they won't do that.

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

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

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

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

    def foo
      @foo
    end

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

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

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.

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

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?

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.

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.

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

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.

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?

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

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.

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

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.

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

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.

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

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

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

People are given a basic coding challenge. On the level of "parse roman numerals" or similar with some tests, standard kind of basic things that rosetta code will list implementations of in every possible language. The code was to be written in any language the person wanted. This was not timed, and was to be done at home.

50%, easily, didn't work. Many did not compile, or were totally incomplete. One was a broken implementation in C# submitted as a single function pasted inside a word document.

Only one person out of I think 20 sent a zipped copy of all the code, a short instruction of how to actually run it, and included some tests.

After that, I started to understand just why these kind of little programming tasks were given.

> And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict.

Hah. I've had someone who didn't know the difference between local and global variables trying to come in as a fairly high rate contractor.

- read that file in

- store it in some sort of data structure

- allow users to run commands to retrieve movie titles based on name, release year, etc.

Command-line was totally fine, you had access to the Internet, and as much time as you wanted.

At least 50% of people couldn't do it. One candidate spent hours staring at the screen before slipping out with a note left behind, "I apologize for wasting your time"

I may wind up stealing this as an alternative test for more advanced programmers; everything here can be done using the Python Standard library.

And kudos to those of you who suggested in-memory storage vs. writing it out to a table.

But the range of times was stunning. There was a lot of people that managed to pass, but it was a three or four hour exercise (I'm willing to chalk some of that up to nerves or overthinking the problem).

It obviously is, for a suitable loose use of the term, "writing your own database from scratch" (unless you are using an existing library, for which many languages have ones that can be leveraged in the stdlib, including often ones that bring in SQLite). But doing a database of this extremely minimal complexity, or leveraging existing libraries to provide the functionality, is a pretty basic task that anyone expecting to get employed to do software development should be able to do with the conditions described.

I was looking for a couple of months before I went through the process with my current employer, and some of the experiences were just horrible: one company put me through 7 interviews with a single engineer each time, lasting 30-45 minutes, and then brushed me off with a two sentence email. Another wanted me to design an algorithm in 20 minutes while they watched via screen share, and if I couldn't do it in 20 minutes I wasn't good enough for them. Several asked me to take timed tests with prominent counters flashing in the corner. It's just stupid.

So I think personally we should support employers who understand how software is made, and are willing to create the right conditions for you to really practice your craft, and then judge what you've made and how you interacted with potential team mates.

In itself this is a good (dis)qualifier; if I give someone a problem and tell them the data will never exceed 10k rows, I expect them to be practical and not waste time setting up a database.

I don't see why you wouldn't use a database for a problem that it's particularly good at addressing.

But most of the people who successfully passed this didn't use a database, it just wasn't enough data to be meaningful - thousands of rows at most.

- sqlite

- Storable (perl)

- serialize some other data structure to disk

- in-memory

I seem to recall one or two people over the years who wanted to install a relational database as part of the code to store stuff - we were fine with that as long as you then showed all the right behaviors for dealing with relational databases (using transactions, catching errors, etc.)

But most people read it in and store it in memory - there was only a few thousand rows.

- find and display all movies by the specified year

- substring text searches in the title

Maybe one other. But it wasn't even approaching anything really sophisticated. We just wanted to see that people could write a basic logic flow, read-and-write data application.

Then for the people who did finish it, we looked at the code. Was it well commented, well thought out, did it have error handling (what if the input file doesn't exist? What if something eats your data file while it's running?), what assumptions did they make.

So the base test was basically a sniff test - if you can't do this, you're not a good enough developer to work here. If you can do it, we'll look at the quality of the result to assess how senior you are.

So it's just a matter of parsing the CSV into some native data structure in your favorite language and then computing sort indices of the columns by which rows might be queried.

Only once they ask for efficient Levenstein-distance-supporting search do you need to use any brainpower.

N.b. if you choose to parse CSV from scratch, make sure to handle commas in quoted text as well as escaped quotes. The better approach is to grab a library or code snippet and call it a day.

For example in python: 1. Load the CSV file using the csv lib in a list of dictionary 2. Fill a sqlite database with the list 3. Read wathever the user asked for (ex: movies longer than 100 minutes and release date before 1999) and build a SQL query 4. Display results

If candidates reason well about design decisions of their implementation, perfect or not, it at least tells me they are reliable developers who do not jump into coding before thinking carefully.

Yeah, and honestly, that includes hiring managers.

I've rejected offers because the hiring managers level of deception exceeded my tolerance for bullshit.

> About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard.

Yes, I don't remember the syntax from 5+ languages well enough to write it in on a whiteboard. Yet somehow, I'm able to use 3-4 on a daily basis to handle millions of dollars in transactions.

So...I really think whiteboards, once again, are really the wrong way to test people. Code samples and discussing them work much, much better for everyone.

I may be biased...whiteboards, I get rejected 50% of the time. I also find, honestly, that if I ask two technical questions of the people giving the whiteboard test of similar difficulty...they rarely can answer more than 1 acceptably so I've found the failure rate to be pretty consistent with the rate they fail me.

Code samples? I get offers 90% of the time.

Not just the example you gave -- they also lie whenever they list something as "required" and then hire the go-getter who's missing some of the skills.

Yeah, many of these kinds of blog posts strike me as being out of touch with what hiring is like. So don't ask about algorithms, don't ask to write code, don't ask to use a whiteboard and ignore if the candidate can't handle the pressure of a standard interview? How are you expected to weed out unsuitable candidates?

Here are my rules:

1. Phone screen coding is optional. If someone is vouched for by a reliable source, you don't fizzbuzz them.

2. The phone-screen question, if used, should not presume any type of formal university CS education (i.e., asking for algorithm regurgitation is right out). Not every good programmer has a university CS degree (many of the best don't), and even among those who do, the longer they've been out of school the less of that stuff they'll remember. Their brain has long since paged the CS 101 algorithms out or even cleared them entirely to make room for the working set of things that actually turned out to be relevant to coding for a living.

3. Good phone-screen questions have solutions in under ten lines of code. Ideal phone-screen questions have solutions in under five, or may even be one-liners in your company's preferred programming language.

4. Once a candidate is past the phone screen, or once you've decided they can skip it, you get to ask them exactly one more question that involves writing code.

5. The final code question must be realistic both as a problem and as a set of conditions. Your employees write solutions to real problems, in editors or IDEs, so to find out whether someone could succeed as your employee that's what you should test. Being able/unable to solve contrived problems by coding on a whiteboard is a completely unrelated skill and does not indicate or rule out ability to solve real problems in an editor or an IDE.

6. The final code question should be a "homework", designed to take a baseline-qualified candidate approximately an hour or two to complete, but to be completed at the candidate's leisure (i.e., set a deadline a day or two after you give them the problem). They should not have to solve it perfectly in 20 minutes on a whiteboard. They should be able to use common/standard libraries. They should be able to use Google or look things up in books they have lying around. They should be able to try running their code and correct errors that turn up when they do. They should be able to do those things because those are job-relevant skills and job-relevant skills are the things you want to test, remember?

7. The interview portion of the final code question should be a collaborative review of the code, discussing design decisions, tradeoffs, and areas where it could be improved/expanded/etc. Being able to present, discuss and review code with others is a job-relevant skill.

8. In a real dev job, at most 15-20% of a developer's time is spent in directly writing code to accomplish a task. The remaining 80-85% is spent in determining requirements, researching approaches to problems, making design decisions, soliciting feedback from peers, reviewing existing or new-but-peer-written code, writing tests, writing documentation, and performing all the other mental and bureaucratic tasks which accompany the act of coding. In light of which, time spent directly writing code to solve interview questions is not permitted to exceed 15-20% of the total time taken by the interview process. The remaining 80-85% should be focused on getting to know the candidate well enough to determine how they'll do with the tasks that will take up 80-85% of their time on the actual job.

I've done my best to phrase this politely. It's based on (as of this point) 15 years of getting paid to write code and having been on both sides of the interview at multiple companies and for multiple positions at multiple points in that time span. But if it helps, feel free to put it in terms the typical tech interviewer is familiar with and think of this as a sort of fizzbuzz for interviewers/managers: anyone who can't figure out how to implement these things may not be qualified to be an interviewer or manager.

* Excelling through the test never to hear from the company again.

* Being (as admitted by the manager in the interview) one of two qualified candidates, the other one being from a somewhere a few hours away by plane, and then get a really cheap offer.

* being asked in a disbelieving tone if I can still code after working as a system engineer for a while. (yeah, give me an assignment already.)

I'd love to be in more interviews where I could win just by coding small small samples or discuss code on the whiteboard (that is as long as nobody is nitpicking about things that any decent IDE will catch.)

Basic technical interviews are a must, but someone people get hung up on "they couldn't explain a hash map implementation," because sometimes "you put a thing in the map and then get it back out later" is good enough for 99% of startup engineering tasks.

Somewhere out there is a sweet middle ground, but it seems not one agrees where it really is.

Further, they may be looking for factors that correlates with other, hard-to-measure factors. Even such as reading a "common interview questions" book - it correlates with focused pragmatism...

And I disagree that looking up the answers to common interview questions is focused pragmatism. I don't bother, even with the knowledge that it would help me get a job. I spend my time working on side projects or learning practical things. I think I will never in my life have implement a hash map, and that knowing it's all O(1) operations is sufficient. But also I guess I don't want to work for a company that is interested in my ability to jump through hoops. (shrug)

(Standard disclaimer: Some development positions actually require the academic knowledge mentioned. Most of the time, though, a good developer will use a well-tested library instead of rolling their own.

(If anything my experience is that older developers have a stronger tendency towards implementing academically known datastructures themselves, whereas younger developers are more likely to make more use of libraries)

Now if you are asked to come up with a red black tree without any help, now that is a different story. A red black tree's implementation details are hard to derive given a set of requirements. A binary search tree, not so much.

Most of these interview questions aren't designed to be trivia. It's designed because your job IS implementation of technical and business problems.

I don't store everything in my head anymore. I have a general understanding of the concept and a mental pointer in the form of the search term to put in google to refresh how to implement the thing.

I have to implement 10-20 concepts across 5-10 languages or APIs or technologies every single day usually, my brain doesn't work like a database where every record that's inserted is there permanently until I update or delete it. The stuff I'm not using regularly gets fuzzier and fuzzier and goes back to "general concept mode" if I'm not actively using it.

So when someone asks me to write a full iOS app during an interview when I've been making Microsoft business apps for the past year, even though I've written and released multiple full iOS apps at previous jobs, I can't just sit down and produce a perfectly working app like a robot, especially if I didn't have much time to prepare for the interview (that recruiter contacted me three days earlier and didn't tell me he set up an interview until 8pm the night before).

With technical questions it's even worse, because I could have been spending days and days refreshing my knowledge but you happen to choose one of the things I didn't think to refresh my brain on. And so I waffle on the answer and you go "oooh, looks like he doesn't know anything". No, I've got a full decade of making apps and software, in lead roles, in multiple industries with a bunch of different technologies. I know plenty. I just didn't have that question fresh in my head.

Then you pass, and lose out on someone you would have benefited from greatly in favor of the recent grad student that hasn't made anything but toy programs yet got tested on all those concepts within the past six months so it's fresh in their heads.

An aside, but I think interviews like this should allow Internet connections. Give the candidate a minute to look something up and digest it in their own way. It should be obvious whether they'll get the concept or just recite the Wikipedia definition. Just as important is how they do their research, and how they draw connections between foreign and familiar concepts given a blueprint of the former.

Maybe. Or you would scoff, turn your nose up, mutter "noob" under your breath, and move on, knowing you're not going to hire me.

I'm sure you yourself would do as you said, but I can't be so sure about random interviewer person.

Plenty of known-smart, known-qualified people are criticizing tech interview processes. They're criticizing the dehumanizing approaches. They're criticizing the way it wastes the time of everyone involved. They're criticizing the way it produces huge false-negative rates.

And they're right. Many of the people criticizing tech interviewing are precisely the kind of people you say you want to hire but then design processes to exclude. You don't get to shift the blame on that one; if you're really a hiring manager, you should be finding ways to fix, not ways to make excuses for, the tech interview process.

Sometimes the best available option is mediocre. ("It has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time.")

I could pretend that Python was my favorite language, but that's more that I'm comfortable with it than any sort of actual feeling that I should prefer it over others. That is, I use it out of inertia and familiarity, not out of some sense that I've found something.

That's one of the most inadvertently funny things I've read on news.yc in a long time!

I have an issue with this - i don't lie. Not in CV, not in interviews. We're not managers, we cannot talk our way out of tasks given to us, and most of us who are worth at least a pinch of salt are not desperate to get job X.

But I understand that if your experience is as it is, this is probably correct approach.

Well, I don't either. That makes it much better for me that people use a test that separates liars from honest people.

Yes, the phrasing is bad, but it is a very understandable hyperbole.

Also, it can be hard to generate code on the fly in an uncomfortable situation, and breaking the ice is important. I've often wondered if asking individuals to debug, test and fix, or to refactor code, might not be a use way to get a high level look at their product, and ease them into programming mode so when they get to actually writing a function for your next question they are tuned up and ready to go.

Example, if you read a SQL book a couple of years ago, you would say you have experience in SQL. You've forgotten most of it, but you are familiar. If a manager reads that same thing, he or she might think, "Oh, proficient in CRUD queries but not overly complex ones." Manager gives you a quiz on SQL, but since you don't have Google in front of you, you flail because you haven't messed with it in a long time.

It's not really lying, it's just a communications gap. I'm not saying there isn't outright misrepresentation of skills, but most of the time it isn't intentional.

Anything listed on your resume is fair game for questions, especially if you claim it as a skill. "Reading a book" is not a skill; reading a book and using the contents in that book for several real world projects probably qualifies. Especially if you can describe what you did in detail.

Harsh reality: I value everything in that section of the resume at the value of the weakest component that I find. So when we discover that your knowledge of SQL is reading a few tutorials on w3schools ten years ago, I rate EVERYTHING ELSE in that section at the same level (ouch!).

So the safe way to play this is don't list anything that you can't hold a 5 - 10 minute conversation about and explain at least the basics of how the technology works, citing real examples of where you used it (paid or unpaid, I don't care about that, as long as you're clear about what you did).

Yeah. Most of your competitors won't do this. They'll fill out the bottom of their resume with junk. But um... there's a reason they're still looking....

Incidentally my own (technical) resume has exactly two lines of IT skills... each of which I can do a 30+ min speech on. Never had a problem in that area during an interview...

I would say the majority of our hires don't complete it and I always explain that's fine, the point is to observe the process they used to create whatever they created.