[hanginghyena]

Hiring Manager Perspective: Everyone lies, sorry.

As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them.

My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. Entire assignment is 100% job relevant (in fact, my SVP asked for a copy of the report it generates when he saw the problem on my whiteboard). I don't care about the details of syntax.

I do care, however, about candidates who produce SQL code which looks like the bastard love child of LISP and Java. About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard. Who put "certificates" from Oracle on their bloody resume and break down under super gentle questioning and confess their tutor hasn't taught them JOINS (wtf ?) yet, never mind 5 years of claimed SQL experience at a big company on their resume.

The coding question is most definitely not an exercise in sadism. We validated it with several new hires who were confirmed to be "good at SQL". Average completion time: 2 minutes, generally with trolling about why do we waste our time with easy stuff.

That being said, my rejection rate from a basic coding interview is at least 50%, grading liberally and generally supported by several members of my team shaking their head about a candidate.

I've tried screening resumes, I've tried doing non-coding phone screens. IT DOESN'T WORK. Actually, all it does is eliminate the socially challenged and non-communicative (who actually tend to pass the whiteboard test) in favor of the liars.

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.

[MrLeftHand]

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.

[taneq]

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.

[MrLeftHand]

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

[hanginghyena]

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]

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.

[arethuza]

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?

[pkaye]

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.

[asimuvPR]

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

[SilasX]

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

[rhizome]

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.

[SilasX]

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

[rtpg]

Maybe 5 years of Java without using inheritance?

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

[qaq]

... or you are Rich Hickey :)

[MrLeftHand]

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.

[joshyeager]

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.

[pjmorris]

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

[dllthomas]

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

[pedrosorio]

One day?

[sotojuan]

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

[arethuza]

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!

[krzyk]

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.

[hanginghyena]

THIS.

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

[Kluny]

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.

[spenuke]

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.

[fapjacks]

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

[EpicEng]

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.

[llamataboot]

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!

[jsudhams]

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]

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]

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]

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.

[gregmac]

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

[yeowMeng]

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

[golergka]

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

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]

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

[Thriptic]

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

[bobwaycott]

That, too.

[golergka]

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?

[mbesto]

Both responses sound oddly like dating.

[drdeadringer]

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

[kragen]

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.

[anarazel]

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

[kragen]

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.

[st3v3r]

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

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.

[scottlamb]

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

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

[scottlamb]

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.

[IanCal]

I've been on the interviewer side in the past when this was the setup:

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.

[mattzito]

At a previous startup, we gave potential developers a very simple test: we had a file with a comma separated list of movie titles, release dates, etc. The candidate was expected to:

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

[hanginghyena]

Brilliant!

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.

[asimuvPR]

Weird thing is I was writing the code in my head a I read the instructions. Hard to believe people would fail that but years of hiring have shown its true.

[bobwaycott]

If I had access to Python and the REPL, preferably ipython, I don't think I'd even need the Internet.

[mattzito]

Yup - our really good developers would do this end to end in < 40 minutes and without needing anything.

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

[tayo42]

How would you do this without basically writing your own database from scratch?

[dragonwriter]

> How would you do this without basically writing your own database from scratch?

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.

[markbnj]

I absolutely agree with this. Moreover, this basic approach of giving the candidate a reasonable set of requirements, a quiet space, and as much time as necessary is hands-down the best way I can think of to asses competency. It's how I was assessed by a company at which I just accepted a SRE position. There was a homework project, a few "personality" interviews, and then a work day for which I was compensated. I was stressed out with performance anxiety leading up to this naturally, but it ended up being a blast.

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.

[cloakandswagger]

Store it in memory? I doubt the amount of data they provided for a test problem was so tremendous that it required a database.

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.

[brudgers]

The flat line in the bathtub curve is where given "data will never exceed 10k rows" implies no database. On the inexperienced end, people don't understand that 10k rows doesn't require a database. On the experienced end, candidates probably oughtn't to believe it.

[sokoloff]

Absent an instruction to specifically "do not use a database", I feel like even 10K rows suggests the use a database as the data structure and then the DB query interfaces as the interface.

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

[mattzito]

As I think I said elsewhere, we allowed people to use a database if they wanted to (and could install it themselves on the dev VM we gave them), but then we would include looking at how they designed the schema, how much thought did they put into connection handling, etc.

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.

[fapjacks]

Yeah, or you could use the opportunity to demonstrate that you know how to roll your own data structures, provided you've clarified that the dataset isn't likely to grow. Instead of showing them you know how to install a database.

[zjaffee]

What? while sure you might not need a database if you have under 10k rows, if you want any amount of resiliency storing data in memory is a huge mistake as if the current instance of the application fails your done for.

[meggar]

It only displays the data, does not save any changes.

[mattzito]

Well, as other posters have commented you sort of do, but since we let you use libraries and the like, you had lots of options:

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

[tayo42]

I guess my intuition was right. I was mostly curious if there was some other clever way of handling this. Mostly related to being able to query the data arbitrarily

[mattzito]

I don't even remember how sophisticated the querying had to be - I think it was something like:

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

[tetromino_]

By implementing only that 1% of a real database's functionality that this task requires. Consider: you have only one table, no updates or deletes or transactions, fixed schema, and very, very simple queries.

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.

[infinite8s]

And sadly you don't even need to create sort indices. Just reading the data into a list of tuples and a few list comprehensions would provide all the querying needed (it wouldn't be efficient but most candidates can't even get that far)

[Cpoll]

Admittedly a database would make the querying more efficient (this is actually probably a good use case for Mongo), but you could just keep a dictionary for each query-able field if you want better than O(n).

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.

[icefo]

You don't have to, you can use sqlite for that.

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

[Kluny]

Well - I'd probably write my own database from scratch. If the list was short enough and time tight enough, I might just let it be an array stored in memory, but I guess that would cause performance problems after more than a couple hundred lines.

[stuffedBelly]

for interviews I'd say even straight dumping data into the file system and retrieving later when the user needs it would be a somewhat valid approach. It's more important that the candidate is able to explain the reason he choose this approach over holding everything in memory (writing/retrieval overhead vs. memory limitation, etc), given the data size/structure of the assignment.

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.

[meggar]

create a Movie class, for each line read in from the CSV file create a new Movie object and add it to a list. queries would search the list of Movies?

[fweespeech]

> Hiring Manager Perspective: Everyone lies, sorry.

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.

[SilasX]

>Yeah, and honestly, that includes hiring managers.

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.

[seanwilson]

> As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them.

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?

[woud420]

It's quite easy, just use bias. (No, not really)

[ubernostrum]

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.

[reitanqild]

This has other sides as well:

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

[heartsucker]

I've had the same experience. Someone listed 2 years Scala experience on a resume, but couldn't explain Unit, None, null, and Nothing to me. Or the guy this week who had several years of ops experience and when asked "how can you tell what indexes are being used in a SQL query" didn't even know about EXPLAIN.

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.

[coredog64]

That latter bit in the Amazon interview really pissed me off. They saw my resume, and it didn't include a degree in CS. They had a cheap opportunity to ask me questions about data structures (phone interview). So why the hell do they wait until the "fly me across the country" interview to ask questions about implementations of priority queue?

[Chris2048]

To be honest though, just because you can get by without knowing how hash maps are implemented, doesn't mean it isn't useful to know - and if another candidate does know, they would sooner hire them.

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

[heartsucker]

I'm not saying it's not useful to know or that having that knowledge might make someone a better candidate, but it seems like that alone shouldn't be reason enough to reject someone.

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)

[Waterluvian]

I hear you. I'm terrified by the kinds of interviews that want programming trivia. In the last three years I've never had to code a binary search tree. But I should be able to show you I'm very comfortable with Python.

[Spoom]

Devil's advocate: Asking highly academic questions allows employers to be ageist without explicitly stating it, since college grads are likely to be the most familiar with them. This lets them select for younger candidates with less experience and thus drive down developer salary.

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

[lmm]

Why would they want or need to be ageist about it? If it's just about paying low salaries, surely all they need to do to accomplish that is offer low salaries?

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

[manufacturious]

Longer hours, less willing to stand up to borderline abusive labor practices?

[efaref]

How about you show me how comfortable you are with python by coding up a quick binary tree implementation?

[timford]

Python isn't the only capability you're typically being evaluated for, though. A binary search tree is a very simple thing. I think it's reasonable to expect a candidate to come up with a basic implementation of a binary search tree, especially if you are giving him/she hints when he/she gets stuck -- an interview should be a two-way conversation. If you can't come up with something approaching a binary search tree in an hour and with my help, how can I expect you to design a reasonably complex system when the business needs it?

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.

[strickjb9]

As an interviewer, I don't ask this question but if I did then you could impress me by asking what a binary search tree is, then I would tell you, then you explain or write how you would do it.

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

[cableshaft]

They might not be trivia, but they're not presented in the same manner as someone would be doing on the job and/or the candidate isn't given the same access to tools they normally have when working and/or there's an 'on the spot' requirement to answer the question.

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.

[carloscheddar]

Couldn't agree more.

[huehehue]

That's usually not how it works though. You're more likely to be laughed out of the room for asking such a silly question, despite the fact the (presumably technical) interviewer could do no better without the teacher's copy in front of them.

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.

[st3v3r]

"As an interviewer, I don't ask this question but if I did then you could impress me by asking what a binary search tree is, then I would tell you, then you explain or write how you would do it."

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.

[ubernostrum]

Tech interviewing is awful. Don't give me excuses for why you do awful things, or try to say "well, it's candidates' fault for having to lie and dissemble to get through the process we created".

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.

[dimal]

It's possible to do technical interviewing well. I've done a lot of terrible ones, but at my current job the technical interviews were highly relevant to my work, and not trivia or puzzle questions. We used a laptop instead of a whiteboard. And even though I didn't get everything 100% "right", there was plenty of discussion, so they could see that I knew what I was doing. So they offered me a job. It wasn't an easy interview, but it worked well in my case. And since the other members of the team are very good at what they do, it looks like it's worked for the rest of the company as well.

[seldo]

Doing what you're doing will probably work, in that you'll get decent candidates. But this approach only works for one kind of good developer -- the kind who can survive this kind of interview. Silicon Valley's diversity problem is made worse by interview styles that give false negatives for excellent candidates who lack confidence or just don't think the same way. My thesis is that this test, by giving frequent false negatives, is resulting in a worse pool of final hires than a broader process.

[bradleyjg]

What would you suggest instead that would decrease the false negatives without allowing the false positives to explode? The parent poster named a couple of different things s/he tried that didn't work.

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

[seldo]

You make a good point. In practice, we've not found a reliable way to weed out the false positives that result (I would not characterize it as an "explosion", but there are definitely some). However, we've stuck with this process because we firmly believe that the benefits of having the excellent people we've hired who would not have passed a standard interview outweigh the costs of getting rid of the others.

[singingfish]

I've recently got into the interviewing for devs game. Now we're a perl fairly specialised shop, and we only hire experienced people so that makes things relatively easy (candidates need to demonstrate a depth of knowledge, and . The pool of people around is relatively shallow too. We don't actually need to ask people technically detailed questions about specific algorithms. We have a conversation. From that conversation you can learn a lot. How do you do async programming (answer you structure the code to make it easy for it to scale)? What experience do you have with RDBMSs? (we're looking for higher level answers). What's the difference between jquery and prototype? How do you deal with conflict? What's the most important thing about coding style? And you let the conversation flow depending on what they say and how they answer the questions.

[_asummers]

One of my favorite questions is asking people their least favorite and favorite languages then asking people to give one of their favorite features in the least favorite language, and least favorite features in their favorite language. Shows that they've actually spent time thinking about their tools. You get a surprising amount of insight from it, depending on the answer.

[maxerickson]

This question would throw me for a loop because I don't have anything I think of as my least favorite language.

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.

[_asummers]

See, but that's a reasonable answer. I might take that and pivot to like "if you had to design an ideal language, drawing from the strengths of the ones you've worked with, what would you think most important?". The idea is to get you talking about things you've worked with to show familiarity and critical thought about your tools.

[singingfish]

Yes that's a good question, I wouldn't like to have that without notice in an interview :)

[SilasX]

I hate the question -- I do think about my tools, constantly, but whenever I've been faced with that question, I don't have a "best" and "worst" lined up, and have to think about the question for a few minutes to recall all the moments of frustration, and so anything I give on-the-spot will sound stupid.

[lmm]

I hate that one because I think Scala basically gets it right, and so I can't really give a good answer to least favourite feature in it. It's my favourite language precisely because I don't think there's anything massively wrong with it!

[lmm]

Doesn't that risk hiring someone who says the right high-level things (maybe they've read some books) but can't actually do anything at the concrete implementation level?

[singingfish]

Yes this is true. But I'd be hoping they'd also have something on github or the cpan, or other places to show their general thought processes. Or at minimum a credible recent employer and references to back it up.

[sokoloff]

> in fact, my SVP asked for a copy of the report it generates when he saw the problem on my whiteboard

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

[saiya-jin]

> Everyone lies, sorry.

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.

[marcosdumay]

> I have an issue with this - i don't lie.

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.

[lsiebert]

Unless handwriting is a big part of the job irl, it shouldn't be for the interview. White board for drawing a db schema or something, maybe, but programmers type.

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.

[CSMastermind]

I honestly can't think of a time I lied during a job interview. Am I doing it wrong?

[Clubber]

It's usually over-promoting a skill on your resume. It might not be nefarious or intentional, but it's a communications gap. What you mean by "experience in," and what the manager wants you to mean by "experience in," are two totally different things.

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.

[hanginghyena]

With a truly technical manager, this is honestly one of the fastest ways to torpedo your credibility.

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

[FussyZeus]

We do interviews in person where I ask a few basic questions and listen for the answer, then assign a somewhat complex problem to be solved in a pre-prepared iOS project. Google fully allowed. I'm not even looking for a 100% functional solution or even particularly elegant code, I want to see how a candidate reacts to pressure and how resourceful they are.

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.

[uremog]

Don't feel too bad, once HR sent a guy to one of my tech interviews who was a male nude model with no programming experience or knowledge - or anything core to the company for that matter.

[qaq]

Hmm now I feel bad about asking questions on transaction isolation levels.