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

Destroy all hiring processes

b-list.org

Post reply on HN
Print view View original

41–50 of 104 posts

Re: Destroy all hiring processes

#41

Post by hatsix »

dustywusty wrote: post #9

As both an interviewer and interviewee at Weebly, I'm pretty confident in saying I prefer our approach of the trial week. It really gives a great opportunity for the candidate to show off their skills without the on-the-spot pressure of a coding interview. A great side-effect is the candidate gets to determine if they like the team, and vice versa. I honestly wouldn't work somewhere else where I couldn't come in for…

How many interviews can you afford to have like this?

Likely, the decision was already made by you being willing to risk the week of vacation and put in the effort to get hired, while they showed a similar regard.

You might be able to get away with 1 or 2 of these things a year... but it's a REALLY good way to burn bridges.

Re: Destroy all hiring processes

#42

Post by NullCharacter »

As someone in the computer science/cyber security field who didn't go to college, I tend to agree with this article in a few ways. Having no college degree has really hindered me in terms of landing interviews, but once I'm given a chance on the job I'm always flourished and proved my worth.

I've also found it strange that it didn't matter what my degree was in, just having one wold have secured me interviews. A theoretical degree in Turfgrass Science would have benefited equally as a proper degree in CompSci.

Re: Destroy all hiring processes

#43

Post by qmalxp »

msoad wrote: post #16

I'm working on open source stuff for two years now. Everything I do is public for everyone to see. Including my responses to bug reports and design documents. Yet I get the same algo/ds puzzle questions that you should've solved before in order to solve it in an interview setup. Google reached to me and said based on my profile I can skip the phone interview but I'm so afraid of the interview that I postponed it mult…

It's not impossible to solve those types of problems if you prepare ahead of time. I think that problem just requires dynamic programming/memoization, which is one of the things you're told to study beforehand.

Re: Destroy all hiring processes

#44

Post by nickpsecurity »

dustywusty wrote: post #25
tomtang0514 wrote: post #14

Earlier quoted context omitted.

But how do you handle the case that candidates already have a job somewhere else? They can't take a whole week off for this.

I took a week off at my previous job to trial at Weebly. My previous job had a very strict vacation policy, but I knew the importance of what I was doing. Weebly has an unlimited vacation policy, so, it worked out pretty well.

You've mentioned this twice. Yet, it means nothing for vast majority of people in the workplace. The majority have to be at work programming instead of interviewing for programming positions. They neither have unlimited vacation time nor a 100% guarantee using a vacation for some interviews will go anywhere. If anything, the OP's post shows quite the opposite for them in common case.

So, how does a trial week work for candidates committed to another job? If anything, it seems to self-select for part-time or remote workers that are already in a position with time on their hands. The best I know don't fit into that category: you'd miss them.

Re: Destroy all hiring processes

#45

Post by ubernostrum »

aggieben wrote: post #37

> a belief that memorizing a bunch of that stuff and being an automaton who spits back the correct algorithm name and a pseudocode implementation is all there is to programming. Because what companies really want is to hire a Fisher-Price See-‘n-Say toy, right? I get the overall rant. I understand the frustrations - but this is wrong-headed. If you can't see the value of understanding algorithms - learning both how t…

It's more that there's a lot of cargo-culting and "Google did this, so it must be good" flying around, and a lot of really bad CS programs which revolve more around the Feynman-rant memorize-and-regurgitate style than actually understanding performance characteristics. Which in turn produces interview processes that really are of the See-'n-Say variety.

Though to be honest, for a lot of what I do my working set in memory (metaphorically) involves very very little algorithms/data-structures stuff and a lot more quirks of libraries/frameworks/protocols stuff. When I need the algorithms and data structures, I pick up the reference I keep on my desk and look up the thing I'm thinking about to double-check that I'm using the right approach.

Re: Destroy all hiring processes

#47

Post by skimpycompiler »

msoad wrote: post #16

I'm working on open source stuff for two years now. Everything I do is public for everyone to see. Including my responses to bug reports and design documents. Yet I get the same algo/ds puzzle questions that you should've solved before in order to solve it in an interview setup. Google reached to me and said based on my profile I can skip the phone interview but I'm so afraid of the interview that I postponed it mult…

These problems aren't that hard, although they do not say anything about the person that solves them. One can prepare for a Google interview in 1-3 months and I'm sure there's a pretty high chance they would pass it.

I've seen tens if not more people from my unknown middle EU university nail the interviews, ending up with jobs at Google, Facebook, Microsoft etc. and I've cooperated with some of them, knowing that their programming skills and knowledge, teamwork are lacking. But they can solve some simple dynamic programming problems, or maybe a silly breadth-first-search, and they'll get the job.

I, personally, wouldn't like to be hired at a firm that evaluates me that ridiculously. Yes, I'm a fresh graduate but thinking that knowing Dijkstra's algorithm evaluates my abilities makes me believe the whole culture is entirely deformed and I do not want to be fascinated by these ridiculous puzzles when I'm working with others.

Give them a week to implement something of larger complexity and they are drowned by so many concepts they decided to skip to earn an internship/full-time position at their beloved giants.

But I guess giants can afford having engineers that aren't that productive, or aren't doing projects that matter. I wouldn't like to be one of these engineers.

So, the real question is do you want that, or is the cash blinding you? :D

Books like these below can increase your chances significantly:

http://www.amazon.com/Elements-Programming-Interviews-Inside...

http://www.amazon.com/Competitive-Programming-3rd-Steven-Hal...

http://www.amazon.com/Cracking-Coding-Interview-6th-Edition/...

Re: Destroy all hiring processes

#48

Post by xacaxulu »

Mithaldu wrote: post #2

> even if we don’t have a sense of ethics we do have a problem of numbers, and more desks and seats and spots than people to fill them I get this a lot, but it is amazingly self-inflicted. Almost all of the random job offers i seem to be getting from people i don't know are from clients who: - underpay - demand on-site only - don't even look at the copious provided code samples, only at the CV The reason for that is…

>> demand onsite only!!

The companies making the most demands usually offer the least. My favorite new flavor is recruiters saying "well for remote the pay rate is lower" to which I answer, "will I be doing less work in that case?".

Re: Destroy all hiring processes

#49

Post by thaumasiotes »

dx211 wrote: post #23

A couple of years back, I was hiring some vendor developers for my team, and since I had some flexibility in the interviews that wouldn't be allowed for full-time employees, I tried an experiment: For one of the vendor candidates, I told him a day ahead of time that I'd be asking him to implement System.Collections.Hashtable in C#, with behavior equivalent to the one in .Net. The day of the interview came, and he whi…

I recently interviewed with a company that had advertised (in my paraphrase) "we've noticed that a lot of perfectly good developers do poorly in interviews for reasons that appear to be unrelated to job performance. So you can now interview with us by completing a project on your own time, and during the interview we'll talk about that".

My project was a regex matcher. I ended up getting the following feedback:

> We thought you wrote a great, very full featured regular expression matcher. It was especially impressive how much you dug into the academics behind regular languages.

> However we made the decision because we felt that while going through the project together during the interview, we didn't see the fluency of programming when adding to it that we had hoped for. While we specifically designed the take home project track to help overcome the difficulties of coding under time pressure with someone watching, we do still need to see a certain level of programming during the interview. This didn't seem to be the case here.

It's hard to know what to do with that. :/

Post reply on HN