201–210 of 524 posts
Earlier quoted context omitted.
This is pretty standard in the UK. Your new full-time job is commonly effectively at-will for the first 3 months, and possibly more. See, e.g., http://www.jobsite.co.uk/worklife/probation-periods-19677/
As far as my experiences go, US companies (at least at the enterprise level) generally seem to have ~4 month probationary periods for new hires.
"It turns out that most people would put together a Rails app with more lines on their Gemfile than lines of actual code they wrote. Worse" - how is this worse then rewriting the wheel? write code only when you must
Earlier quoted context omitted.
The fact they have to filter down from a large number of applications to a small number of roles doesn't say anything about how selective they are. SELECT TOP 1000 FROM resumes ORDER BY received_date will produce 1000 job offers but speaks nothing to selectivity.
> filter down from a large number ... to a small number ... doesn't say anything about how selective they are. But that's what the definition of "selectivity" is for database retrieval. Selectivity == n_rows_selected/n_row_count. The " larger number " was the denominator and the " small number " was the numerator. Your example SQL is not consistent with your previous sentence: SELECT TOP 1000 FROM resumes ORDER BY re…
> As brain-dead as I was after eight hours at my project, [..] Is giving out an 8+ hour programming project as part of the application process really considered good hiring practice? If you apply to five jobs, you're expected to spend an entire unpaid work week writing code that doesn't benefit anyone? If a company receives 20 applicants, their ideal candidate selection wastes a collective work month? I don't really…
As developers, we often take a 5+ hour whiteboard interview on some of the fundamentals of CS, but presented as challenging problems. We may also have to do a take-home "project" which can be viewed as a "practical" component of a comprehensive.
I don't object to this per se. What I dislike about it (as I've mentioned on HN before) is that we take these exams without the protocols that evolved over centuries in exam-heavy institutions (universities, professions) to safeguard against abuse ensure the process is fair and decent to the people taking the exams.
The exam must not be capricious, it must be relevant and consistent across candidates, it must be created and assessed by competent members of the profession, there must be an associated study path, the content of the exam should't be a huge surprise to the candidate, candidates are provided with feedback should they fail.
And, perhaps most importantly, the process of taking and passing the exam provides the candidate with a certain stature, a lasting credential that is widely respected in the profession. The candidate doesn't have to re-take this exam over and over every time he or she interviews (in many ways, that is the point of the exam).
In many ways, I feel that programmers experience the downsides of this sort of professional entrance exam but without the positives.
I'm glad to see this discussed on HN, because I really do think that software "interviewing" as entrance-exam is one of the things that eventually drives people out of the field (or causes them never enter it in the first place). It's not a good thing for our field.
I'm not saying it's an easy question with an easy answer, just that our current approach is failing.
Earlier quoted context omitted.
This is just not true. I talk to interviewing developers every day, and very few of them are interviewing at Google. The final round of on-site interviews usually eats a whole day, and is preceded by a whole battery of time-wasting phone interviews, which themselves eat as much time as a coding challenge and often involve coding with someone else over the phone or Skype . There are companies that are not Google that…
Are they not only getting very desperate candidates ?
A couple of months ago I did a 'homework' assignment for an interview (it involved writing a simple REST service in go, even though I have at least one personal project demonstrating exactly this skill -- to an even greater degree -- in my github profile). During the phone-discussion after turning in the project, the mid 20-something lead developer couldn't find anything to nitpick (I could have) and even told me he…
Last week, I finished 2-3 hours of on-site interviews which required a flight and an overnight stay after an initial phone screen, a phone technical interview, and a short technical challenge online. I was surprised how a couple really basic concepts evaporated from my head during the in-person white boarding. The questions though were reasonable and the interviewers were friendly. All in all a positive experience ju…
A couple of months ago I did a 'homework' assignment for an interview (it involved writing a simple REST service in go, even though I have at least one personal project demonstrating exactly this skill -- to an even greater degree -- in my github profile). During the phone-discussion after turning in the project, the mid 20-something lead developer couldn't find anything to nitpick (I could have) and even told me he…
Indeed, I agree
Earlier quoted context omitted.
No. That's not how a market works. Google can in fact maintain high and consistent standards for incoming developers. But because their processes are so dysfunctional, they overpay to do it. And engineer headcount costs are a huge component of their business --- so much so that they've been accused of breaking the law to collude with other companies to avoid competition in hiring! Google is succeeding in spite of the…
>Google can in fact maintain high and consistent standards for incoming developers. But because their processes are so dysfunctional, they overpay to do it. But there's no evidence that switching to self-paced work samples would cost them less. With Google's popularity, they'd get more false-positives from candidates that copied the code from widely disseminated previous projects. False-positives cost money. Your med…
Google is manifestly too capriciously selective in their interviews. They are infamous for turning down people who go on to do excellent stuff elsewhere. Watching acquaintances navigate their process makes me believe the infamy is well-earned.
That's an argument that is separable from the question of how best to design the Google interview process. I think Google's interview process should be work-sample based, like I think every tech company's should be. But you could argue that either way. We can both agree that Google's challenges are sui generis. We're both reasonable and might disagree on the rest of it.
Where I don't think reasonable people can disagree is on the question of whether Google overpays for engineers. They do. They pay a tax for the luxury of being capricious about who to hire. They can afford to do that, but most companies can't.