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

261–270 of 315 posts

Re: People suck at technical interviews (2014)

#261

Post by cmdrfred »

hanginghyena wrote: post #224
MrLeftHand wrote: post #88

Earlier quoted context omitted.

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, don…

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…

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.

Re: People suck at technical interviews (2014)

#262

Post by dagw »

bobwaycott wrote: post #256
golergka wrote: post #251

Earlier quoted context omitted.

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

Two ways I can think of off the top of my head: 1. Total reliance on ORMs, and never actually touching SQL (or not in 5 years since you started using ORMs) 2. Not building complex relational schemas with related items that you use SQL to pull in results of combined data that follows those relationships. I'd wager #1 is the more common case.

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

Re: People suck at technical interviews (2014)

#264

Post by overcast »

SilasX wrote: post #247
overcast wrote: post #166

Earlier quoted context omitted.

It's ALWAYS about who you know. Always.

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 work (sounds like you’re on the fence?) I’d recommend mass applying, and also moving here to start interacting with folks and getting to know people. Building a network is so, so valuable for getting a foot in the door."

Unless this guy is some type of programming prodigy, who in only two years of self learning, somehow blew away all top companies, only to be turned down, then what happened was that he has friends in high places that helped sway their decision.

To be completely honest, the entire article smells like a marketing campaign for TripleByte and AppAcademy. Google wanting to put him on the C++ team, after two years coding in Rails? Get the hell out of here.

Re: People suck at technical interviews (2014)

#265

Post by bobwaycott »

dagw wrote: post #262
bobwaycott wrote: post #256

Earlier quoted context omitted.

Two ways I can think of off the top of my head: 1. Total reliance on ORMs, and never actually touching SQL (or not in 5 years since you started using ORMs) 2. Not building complex relational schemas with related items that you use SQL to pull in results of combined data that follows those relationships. I'd wager #1 is the more common case.

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

That, too.

Re: People suck at technical interviews (2014)

#266

Post by liquidise »

I had actually written a post a few months back[1] that bares a remarkable similarity to this one. It's encouraging to see others have, and are, coming to similar conclusions. Remember that each person who learns these methods now improves a round of interviews in the future.

1: https://blog.benroux.me/4-steps-to-making-your-interview-suc...

Re: People suck at technical interviews (2014)

#267

Post by dagw »

cm3 wrote: post #75
gavanwoolery wrote: post #34

Earlier quoted context omitted.

If they had a killer hook, yes. An editor can always review and fix the grammar. :) A coding analogy: A compiler or debugger can catch bugs. If they can't form a competent sentence, they probably would fail to write a convincing hook. But some margin of error is acceptable.

While true for writing books, I wouldn't consider code that doesn't pass a linter or compiler a useful part of one's portfolio. There is no editor equivalent who will fix your syntactic and semantic errors for you, and getting that right is an important part of your experience with a language/tool.

There is no editor equivalent

It depends on what you are working on. A non-trivial part of my job involves working with domain expert scientists and taking their very clever, but badly written, code that solves some hard problem and turning it into fast, efficient and usable code.

Re: People suck at technical interviews (2014)

#268

Post by meggar »

zjaffee wrote: post #252
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.

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.

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

Re: People suck at technical interviews (2014)

#269

Post by Thriptic »

dagw wrote: post #262
bobwaycott wrote: post #256

Earlier quoted context omitted.

Two ways I can think of off the top of my head: 1. Total reliance on ORMs, and never actually touching SQL (or not in 5 years since you started using ORMs) 2. Not building complex relational schemas with related items that you use SQL to pull in results of combined data that follows those relationships. I'd wager #1 is the more common case.

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

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

Re: People suck at technical interviews (2014)

#270

Post by fapjacks »

spenuke wrote: post #259
Kluny wrote: post #236

Earlier quoted context omitted.

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…

That's fine, but you have 3 years of experience with a CMS. SQL is the Structured Query Language used to make queries, so if you're not writing that, then you aren't working with SQL. I've been driving cars for twenty years, but it doesn't mean I have two decades of experience with fuel injectors.

Your example makes your point very well. You are totally right.
Post reply on HN