11–20 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 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 requirements? These are the things you can't find the answer to in 30 seconds on stack overflow.
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…
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.
Imagine you hired some Cobol developers some decades ago, and therefore you would still be stuck using Cobol on your projects.
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…
If only there were some way an employee could learn about btree's after taking a job...
Recognition is easier than rediscovery.
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 cherry picking something that supports my beliefs but it was here nonetheless.
Also, I have interviewed a lot of people with 4.0 BS/MS in 5 years that turned out to be horrible employees. They were awesome with the brain teaser questions but sucked when they actually had to build something.
I guess I do not see how you can lose if you take the contract-to-hire approach ..
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.
Why should Oracle be any different?
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.
What about just some things. And in most cases, it's not learning for the first time but brushing up on the topic. To expect people to have encyclopedic knowledge of every edge-case problem your company deals with on a day-to-day basis is ridiculous.
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.
If you're asking interview questions that can be googled in 20-30 seconds, you're wasting your time and theirs.
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 think the attitude of "they should hire me, since I can learn anything" is self-centered. There are a lot more people that can't learn. Without testing methods available there is no way to distinguish the self-starters from the frauds.