Live data from Hacker News

Who Y Combinator Companies Want

data.triplebyte.com

431–440 of 552 posts

Re: Who Y Combinator Companies Want

#431

> "We’ve seen that most engineers only have the stomach for a limited number of interviews. Investing time in the wrong companies carries a high opportunity cost." I suspect in addition to not having the "stomach" for an unlimited number of interviews, they don't have the vacation days to burn for them. Let's say you are working already and have 10 days a year vacation (pretty standard). With these ridiculous all-day…

I've long felt that a lot of software companies are keener on interviewing than they are on actually hiring. There's got to be a breaking point somewhere where too much time spent interviewing is actually a net loss even if you end up finding good hires, and I wouldn't be surprised if many companies are beyond that threshold.

The company I'm at doesn't employ any magic voodoo in our hiring methods, but we somehow manage to find great people without being a revolving door for interviews. Many places are proud to say that they only make offers to 1% of the people they bring on-site, but I'm proud to say that our ratio is probably more like 25% or even 50%.

Re: Who Y Combinator Companies Want

#432
post #367

Earlier quoted context omitted.

I am pigeonholed. Sure I know other languages: Shell Scripting, Perl, HTML/CSS/JS, Groovy, SQL, C#, etc, but 80 percent of the code I write is in Java. I'm at a Java shop and have golden handcuffs. It's Java or bust for me.

> I just happen to write the majority of my code in Java. If tomorrow we decided to use a new language, I could pick it up in a few days... The languages in your list are: * declarative: HTML, CSS, Groovy (for Gradle), SQL * scripting: Shell, Perl, JS, Groovy (for testing) * Java-clones: C# I found it difficult to pick up Clojure and Haskell "in a few days" when all I had was experience in those types of languages. I…

I agree with you about Clojure in particular.

I did do some non trivial work in Lisp in a graduate class, but its not the same as using it all day. I don't believe I would seek out an opportunity where a Lisp dialect was the programming language of choice, anyway...

(I found ML to be easier to work with than Lisp. I guess it's technically not a pure functional language though).

Re: Who Y Combinator Companies Want

#433

Earlier quoted context omitted.

So does that anecdote reflect poorly on the interviewer, or the interviewee?

I personally would be hard-pressed to answer that question. If they mean diversity by gender and ethnicity...well, for some reason I always find myself in teams largely of white males. Not through any selection process of my own, it's just that is how it works out.

[deleted]

Re: Who Y Combinator Companies Want

#434

Earlier quoted context omitted.

The best programmers do apply. Whatever you think a work-hire test is, that wasn't it. A work-hire test attracts the best programmers. It doesn't repel them. It's a chance to demonstrate their skill. It's also far better: anything is better than the fake contests they're currently forced to endure. Which would you prefer? Spend a couple hours remotely fixing some bugs and adding a feature on a fake iOS app, or spend…

> A work-hire test attracts the best programmers. It doesn't repel them. I'm not the best programmer, but I'm comfortable I'd slot in the top quintile, probably top ten percent, of people that walk through a startup's door. And I'd never even return your call. No work-sample test I've ever seen would take less than four hours. That's a $550 opportunity cost for me at my standard rates. What the hell makes you think y…

>That's a $550 opportunity cost

The typical cost of hiring a programer is way higher than that, more like $30k I'd guess so they could always try paying you $550 to do something semi real? I'm not experienced but I've got a friend who hires remote workers and he says the only way to tell if they are good is to actually hire them to do a small job.

Re: Who Y Combinator Companies Want

#435
post #196

Earlier quoted context omitted.

I'll use myself as an example -- I work as a programmer in the Defense industry. I've wanted out for years. So every so often I start sending out resumes and going on interviews. After wasting about half of my vacation time on (multiple) rounds of interviews with each prospective employer (that ultimately lead nowhere -- most often, a potential employer who inexplicably stops communicating with me), I give up. Then,…

"Whiteboard hazing" Heh. I'm going to squirrel that one away for later. It beautifully captures what's currently thought of as a best practice in tech interviewing.

I've turned down offers when the interviews were like that.

Re: Who Y Combinator Companies Want

#436
It feels like this article contains a huge amount of bias. To sum it up in a sentence... of course 'founders' all want 'product programmers'!

Ask only tenured, hands-on CTOs, and I bet that table would come out much different.

Re: Who Y Combinator Companies Want

#437
post #330
post #196

Earlier quoted context omitted.

I'll use myself as an example -- I work as a programmer in the Defense industry. I've wanted out for years. So every so often I start sending out resumes and going on interviews. After wasting about half of my vacation time on (multiple) rounds of interviews with each prospective employer (that ultimately lead nowhere -- most often, a potential employer who inexplicably stops communicating with me), I give up. Then,…

"whiteboard hazing" there are two types of whiteboarding questions. The kind that's a perfectly reasonable thing to ask (i've had people ask me to develop some simple system... which I think is reasonable, because i'll do that as part of the job) but then there's the solve x algorithm questions. Which ultimately is an exercise in memorization. At this point I've just accepted that i'll have to do that.

>but then there's the solve x algorithm questions. Which ultimately is an exercise in memorization. At this point I've just accepted that i'll have to do that.

Pedantic (but hey this is HN), but I don't think algorithms are a question of memorization all the time. Sure, "implement quicksort" is a bit silly, but "rotate this binary tree" is eminently reasonable as a shibboleth to comfort with data structures

Agree about it not being super useful for a lot of interviews though.

Re: Who Y Combinator Companies Want

#438

> "We’ve seen that most engineers only have the stomach for a limited number of interviews. Investing time in the wrong companies carries a high opportunity cost." I suspect in addition to not having the "stomach" for an unlimited number of interviews, they don't have the vacation days to burn for them. Let's say you are working already and have 10 days a year vacation (pretty standard). With these ridiculous all-day…

You actually take vacation days for interviews? I either call in sick or come in late. I usually provide a plausible excuse, like having to take my cat to the vet. Or maybe my foot is bothering me, and I had to wait to get an appointment.

Just the other week, I ran out for a meeting with a potential new employer in the middle of the day. All I said was I "had to run an errand." If I was less checked out, I would've made up a real excuse and told them I needed to get a blood test.

Most people are totally non-confrontational. You're not going to get called out on your little white lies. Obviously you can't use the same excuse 10 weeks in a row, so mix it up a bit.

Re: Who Y Combinator Companies Want

#439
post #166

Earlier quoted context omitted.

Unfortunately, tinkering in your off-hours is a key way for programmers to keep their skills current. The industry changes rapidly and the skills that were most marketable over the past 10 years are not the same as those that will be most marketable over the next 10. If you're not changing jobs constantly, the rate of tech change at your workplace is unlikely to be enough to keep your skills marketable. So you need t…

Why is this not true in other professions? Why don't hospitals give preference to surgeons who like to dissect frogs in their spare time or build better scalpels on their garage workbench?

Because surgeons are already workaholics with insane work/life balance issues, perhaps? Same for many other professions.

Re: Who Y Combinator Companies Want

#440
The biggest issue in interviewing is the bad inexperienced interviewers. It's very very hard to be a good effective interviewer and in my experience even otherwise very smart programmers are not great at this. Here's few things that would help to find better match and eliminate lot of false negatives:

1. Pre-filtering should be based on candidate's public contributions at places like GitHub, StackOverflow, Wikipedia etc. Pre-conceived notions of someone being C# or academic is just simply bad.

2. Don't ask question that you didn't had to solve doing your job. It's absolutely the hardest part for interviewer to come up with great questions that distill the problem they had solved on the job in to something that can be described in 10 mins and worked on in about hour. Most interviewers are unable to do this and fall back to puzzles stolen from websites or coworkers like them. If you are not smart enough to form the great question using actual problems in your job than you have no business being an interviewer.

3. Don't do 45 minute interviews. That time is too short. Candidate has already taken a day off, there is no reason why you should limit each interview to 45 mins and make candidate rush. Countless great candidate get eliminated because they fall short of 15 mins, do longer initial chit-chat or just take one wrong turn.

4. Strongly discourage interviewers to look for exactly the right answers. Again hard to do than said. Most candidates that sail through problem have very likely practiced similar problem to death. The bad interviewer than penalize candidates who hadn't practiced that same problem VS who luckily happened to do so. Ultimately you are required to eliminate 80%-99% of candidates and this comparison is so handy that interviewers fall for it despite of knowing it.

5. Good interviewers knows the trickiest part of the problem and are willing to help out candidate without penalties. Bad interviewers considers any hints or help as sign of weakness and are mentally subtracting points. If you are an interviewer who thinks that your job is to give problem, sit back and watch the show then you are wasting everyone's time. Good interviews are lively discussion, two way conversation and in fact a collaboration.

6. Bad interviewers ask seemingly easy problem but that has chance of making a big tricky mistake or omission. Interview turns in to sport spectacle to see if gladiator candidate was able to duck the fire from the dragon that was behind him. Good interviewers make sure problems are real problem and not a competition to set up traps that everyone easily falls in to.

It's kind of bizarre that most companies claim that they have huge headcount to fill and they don't find talent while their "rejects" have already been having great jobs at great companies with nice history of career growth and compensation raises. The real problem is bad inexperienced interviewers who have been molded to ask same puzzles they had been asked and have been trained to have expectation for candidate to magically arrive at correct answer with error free compact code under 30 minutes. It's utter nonsense. The result is that most candidates now keep working on puzzles for months which has little relevance to actual problems in job and not even a remote indicator of candidate's passion or ability to take initiative or collaborate or ship something in real production consistently.

Post reply on HN