31–40 of 554 posts
well you better have something to show then such as a public github repo.
Well, I need to interview candidates because I need to know if they are up for the job when systems breaks. If a table query fails because it needs a btree index due to range searches, I want the candidate to know how a btree index works and why it fixes the issue. Also If somebody cant tell me the difference between http udp and tcp, its a no hire for me. So for me, I really want to interview somebody before he can…
I never understood the fascination with asking an applicant about minutia of data structures and algorithms. Isn't that the domain of reference material? I gain much more insight into a person by asking them to describe a large system they've designed, what choices they made, the effects those choices had, ect. How did their initial assumptions hold up through the course of the project? How did they adapt to changing…
Well, I need to interview candidates because I need to know if they are up for the job when systems breaks. If a table query fails because it needs a btree index due to range searches, I want the candidate to know how a btree index works and why it fixes the issue. Also If somebody cant tell me the difference between http udp and tcp, its a no hire for me. So for me, I really want to interview somebody before he can…
I never understood the fascination with asking an applicant about minutia of data structures and algorithms. Isn't that the domain of reference material? I gain much more insight into a person by asking them to describe a large system they've designed, what choices they made, the effects those choices had, ect. How did their initial assumptions hold up through the course of the project? How did they adapt to changing…
I like oracle way of hiring. You got a degree from a decent college with decent GPA you are in. Very clear and straight forward. If you got in a decent college and graduated with a decent GPA - you are smart and somewhat hardworking, you should be doing well in your job.
Google recently revealed that going back over the data they kept about past hires demonstrated that an individual's GPA was completely independent of the quality of their future contributions to the company. Why should Oracle be any different?
What I understood from parent was: good college + good GPA => meets minimum hiring criteria, so make them an offer.
What you are saying is: (good college, good GPA) is not correlated with magnitude of performance among PEOPLE ALREADY HIRED INTO GOOGLE.
The other irritating thing is that people seem to prefer selecting people who are technically more intelligent than they are, but who are less socially apt that they are. It's so bad that I think entrepreneurs need to think about protecting their employees from themselves, because this cannot possibly be good for companies in the long run.
Lets just face it. Engineers often times have low self-esteem (especially compared with "business types")(edit: myself including), and interviews frequently become the one place where they can be on top. It's always re-posed as some "meritocratic" test of skill (isn't it always?), and it's anything but, because an interview setting is not effective at measuring whether someone has the initiative and creativity to get a job done.
Well, I need to interview candidates because I need to know if they are up for the job when systems breaks. If a table query fails because it needs a btree index due to range searches, I want the candidate to know how a btree index works and why it fixes the issue. Also If somebody cant tell me the difference between http udp and tcp, its a no hire for me. So for me, I really want to interview somebody before he can…
I suppose if you're a network engineer http/udp/tcp is necessary to know maybe off hand but not really, http isn't even in the same network layer so I'd find it strange to even ask about the 'difference'. UDP and TCP differences are more or less a well known question but even then I've had some ask the question expecting the most basic of differences and others with the minutiae. btree index is also something that ca…
Why? You just answered it well enough. There are people who could not say what you just said; you don't want to waste your time on them.
I have passed a bunch of job interviews in the past - but I feel the exact same away and hire this way these days. I really do not see the point of brainteasers or white board coding questions if you have a budget where you can just pay out a contract like this. Also, I believe there was an article posted here a few weeks back that indicated Google's brainteasers did not lead to quality candidates - I know I am cherr…
I guess I do not see how you can lose if you take the contract-to-hire approach I agree with most of what you said, but one way you can lose if you insist on contract-to-hire is that you are filtering out a portion of the highest quality candidates who are only interested in immediate full time hiring.
It also gives the candidate a way to see what kind of problems he'd be working with, and the quality of the code-base, working conditions, etc.
I think it's a win-win.
the brainteaser-whiteboard-fizz-buzz-5-member-panel interview is, and has always been, highly unreliable, if only for the sole reason that PEOPLE GET NERVOUS. gee whiz, what a concept. back here on earth us mere mortals have to deal with things like nervousness, forgetfulness, and intimidation on a regular basis.
let's not forget sociopaths or assholes in a bad mood who deliberately try to make people feel nervous. they exist. that's a thing. i've seen it with my own eyes.
it is an unreasonably strict high-pass filter that gives false negatives people who are otherwise perfectly valid for developer jobs. that's great if you've got millions or billions in the bank and have carnegie mellon grads lined up out the door. that's awful if you've got $50k in the bank and you need someone competent working on things yesterday.
SO much value can be won by hiring people who can't or won't deal with this kind of scenario. on both sides of the table.
Earlier quoted context omitted.
If only there were some way an employee could learn about btree's after taking a job...
I don't want my employees to have to learn everything just-in-time. By that logic, the people you hire wouldn't need to know anything. In addition, they don't know what they don't know, so they may not even know that they need a btree index.
You can require knowledge without using dealbreakers like "you must know b-trees". A better alternative would be to say "you need to know 30% of the following group of things: b-trees, tcp/ip vs udp, ..." and so on.