Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

People suck at technical interviews (2014)

seldo.com

Post reply on HN
Print view View original

271–280 of 315 posts

Re: People suck at technical interviews (2014)

#271

Post by rhizome »

SilasX wrote: post #177
arethuza wrote: post #113

Earlier quoted context omitted.

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?

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.

Re: People suck at technical interviews (2014)

#272

Post by mattzito »

tayo42 wrote: post #255
mattzito wrote: post #230

Earlier quoted context omitted.

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 fo…

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

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.

Re: People suck at technical interviews (2014)

#273

Post by fapjacks »

sokoloff wrote: post #244
brudgers wrote: post #214

Earlier quoted context omitted.

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.

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.

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.

Re: People suck at technical interviews (2014)

#274

Post by mattzito »

sokoloff wrote: post #244
brudgers wrote: post #214

Earlier quoted context omitted.

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.

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.

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.

Re: People suck at technical interviews (2014)

#275

Post by mattzito »

bobwaycott wrote: post #257
mattzito wrote: post #103

Earlier quoted context omitted.

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…

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

Yup - our really good developers would do this end to end in 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).

Re: People suck at technical interviews (2014)

#276

Post by SilasX »

rhizome wrote: post #271
SilasX wrote: post #177

Earlier quoted context omitted.

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

Re: People suck at technical interviews (2014)

#277

Post by EpicEng »

Kluny wrote: post #236
arethuza wrote: post #113

Earlier quoted context omitted.

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?

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…

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.

Re: People suck at technical interviews (2014)

#278

Post by manufacturious »

lmm wrote: post #191
Spoom wrote: post #145

Earlier quoted context omitted.

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 devel…

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)

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

Re: People suck at technical interviews (2014)

#279

Post by SilasX »

overcast wrote: post #264
SilasX wrote: post #247

Earlier quoted context omitted.

That's not what I got from the story -- he mentions how he got warm referrals (the "who you know") to employers that went tepid quickly after the interview ... but then the same ones suddenly wanted him once he claimed (truthfully, though without proof) that he had standing, big offers from other employers.

"In the end, I didn’t get a single offer through a raw application. Every single offer came through a referral of some kind. (This I did not expect, and strongly influences the advice I’d give to a job-seeker.)" " Haseeb Qureshi says: 04/23/2016 at 9:53 am I’ll be writing more about this in my subsequent blog post. But if you have no connections at all in SV, then I might say that if you’re set on SV as a place to wo…

Ah, right, I forgot about that part. Even so, the point remains that it isn't only about who you know, because he had those connections and leads still went stale, until he gamed the system.

But I would agree that it reveals how confused and manipulation-prone the hiring process is; if they're hiring someone for critical, technical C++ work after only two years experience on mostly-Rails, they really don't know what they want. Ditto for upping their offers so significantly based on things that shouldn't matter that much.

I'm likewise skeptical about how Airbnb would tolerate him revealing sensitive details of a negotiation like that in ways that reflect very badly on them and weakens their bargaining position on future hires. Sure, you don't want to fire an employee just for disclosing his compensation (major legal issues there), but his post went way beyond that.

Re: People suck at technical interviews (2014)

#280

Post by dimal »

ubernostrum wrote: post #253
hanginghyena wrote: post #76

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

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…

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.
Post reply on HN