This looks like a real bug to me. The problem is that many apps use/dev/random instead of/dev/urandom, which of course causes them to be unnecessarily slow.
A "hack" was to make/dev/random behave like/dev/urandom, but it's not clean, which is why it's not done in the official version.
It is as you say: you mostly need to quickly find your way, understand the big picture of how everything works together, understand other people's code, identify where a problem comes from and troubleshoot it, etc. Code I've seen in the industry usually has no documentation whatsoever and often disparate coding styles across modules, so you're on your own. You also need to be able to write software so that it's understandable by others, and if you're doing software infrastructure changes you need to make sure it is sufficiently flexible and non-intrusive so as to minimize impact on other people's code; indeed, it's easy to break stuff by doing what may look like a benign change, and the code is often so large than many refactoring efforts could not be done by hand. The more software becomes large and complex, the more testing becomes critical as well.
Those are critical skills for software maintenance and bug fixing, which are a very large portion of software development, and are mostly acquired through experience. In my experience, new developers are not well-trained for this and are usually quite overwhelmed by large amounts of code, so much that their productivity is very low at first.
I personally find it very difficult to write code on whiteboards (or even paper). Sorting algorithms are definitely not terribly difficult per se (graph stuff is usually worse, and is still undergraduate level), but it's not a walk in the park either, and can be difficult when it's entirely unexpected and under stress.
By large-scale software development I meant doing software development over large code bases. It is significantly different to work on a standalone toy project than to work on millions of lines of code with many other people.
I have hired several, though I use a peculiar screening process. The company I own works a lot with a public research lab; we often hire people that have demonstrated good skills at internships, postdoctoral or engineer work at the lab.
If there is no one on the job market for the job, you outsource, or you delay the project until you find someone.
Fizzbuzz is not even a test of undergraduate level. More like a test of "do you know a programming language". This doesn't even take a minute to do, I was talking of actual tests.
Companies that offer higher salaries than the average typically require work that may span several days, and which does indeed have a bit of undergraduate-level stuff in it (data structures and related algorithms, basic parallel programming and synchronization), which has nothing to do with real-world code. I do not mind doing grunt work if that's useful to the project being developed. Alas, I spend a lot of time doing code refactoring or maintaining the building and testing infrastructure, which is hardly exciting, but necessary. What I do mind is being evaluated on the quality of my grunt work.
I remember quite a few years ago out of university I applied for a job where they asked me to write a program that returned the i-th number that satisfied a given predicate, with i bounded, with the goal of making the program as fast as possible (the predicate in question had certain analytical properties that were to be used to make the search faster). Since there were few numbers satisfying that predicate within the specified bounds, I just made a program that returned the i-th value in a pre-computed table. In a real world situation, for the problem as phrased, this is clearly the best solution: very short development time, maximum performance. But this is not what the test was for, so I got rejected. Tests are just stupid. Use real-world experience for evaluation.
You usually need at least 1,000 to 10,000 lines of code to have any idea about the quality of the code you're reviewing. That doesn't seem like a reasonable amount for an interview.
If you want to review his code prior to the hire, just ask him what open-source projects he's contributed to.
Being good at large-scale software development or at writing robust device drivers will not make you better at doing trivial programming tasks. You must be a clueless manager to think that because someone is a better programmer he can piss code 4 times faster. The problem lies in the fact that those tests do not highlight your skills at all. Since whether you'll go to next stage of the hire or not depends on how good you did at that test, this is really an issue. The most important thing that decides whether a software developer will choose to work for you is whether he feels valuable and useful to your projects. If you're asking him to do monkey coding, he'll just go look elsewhere.
You only interview people with significant credentials. If someone has 10 years of experience doing bleeding edge stuff, asking him "can you spend a few days of your time, that is worth $1000/day, to do something trivial and entirely useless for free, just to see if you're at least as good as a college graduate?" is not really a good idea.
It's not like experienced people have problems finding jobs anyway. A student out of university needs to find a job, but someone with experience already has a job, and is usually just scouting to find exciting new projects elsewhere. The difficulty is usually for the company to find really competent people, not the other way around, so they should try to be as nice and attractive as possible. If you make applicants do demeaning tasks, you're only repelling them.
Except your interview only shows he's at the BSc level, which doesn't say much at all. Would you also like to test if he knows his multiplication tables?
If you want to know whether the CV is true, you can contract a company specialized in verifying background (or have it done by your own HR people). They'll call whatever previous employer he may have had, or verify accountability of whatever company he may have owned. Googling people can also be useful, especially for software-related jobs.
What's relevant is whether the person is a good fit to do what you need him to do. Testing whether he's good at unrelated basic stuff is indeed irrelevant to whether he has the skills needed for your project.
Of course they can, but you have to understand that people have limited time (since time is money), and since this is ultimately useless because it says nothing about the actual value of the person you want to hire (if you only need him to do that level of things, why not hire someone cheaper instead), the applicant would rather not waste his time with this. Applicants seek jobs where their particular skills are put to use, so that they can justify asking for high salaries.
A senior software engineer will not be significantly better than a junior one at solving trivial problems. If you want to evaluate his skill, ask him to do something that's relevant to the added value that's making you hire him in the first place.
I've seen interviewers ask experienced applicants with PhD in various fields of computer science to write the algorithm for quick sort on a whiteboard. Many people can't do it; after all, why would you know by heart an algorithm irrelevant to your domain that you never implement since it's already been done so many times? Even if you remember the principle it's the kind of thing that's difficult to re-code on a whiteboard. Young graduates have a better chance at this, since they just studied it as part of undergraduate computer science class. It's entirely useless and a waste of everybody's time.
Slashdot Mirror
This looks like a real bug to me. /dev/random instead of /dev/urandom, which of course causes them to be unnecessarily slow.
The problem is that many apps use
A "hack" was to make /dev/random behave like /dev/urandom, but it's not clean, which is why it's not done in the official version.
If you can't seize control of your brain, then you're just an animal..
100M is not that much money.
Invest it to get more money.
How is using a bot to farm millions any different than what financial companies do?
Committing suicide is just an act of stupidity.
It doesn't make me sad, it makes me mad that people would do this.
Can't you just download your eroge from the internet or import it?
Official publishing in a country is only useful for mainstream games.
Isn't that the location for an underground alien complex?
It is as you say: you mostly need to quickly find your way, understand the big picture of how everything works together, understand other people's code, identify where a problem comes from and troubleshoot it, etc. Code I've seen in the industry usually has no documentation whatsoever and often disparate coding styles across modules, so you're on your own.
You also need to be able to write software so that it's understandable by others, and if you're doing software infrastructure changes you need to make sure it is sufficiently flexible and non-intrusive so as to minimize impact on other people's code; indeed, it's easy to break stuff by doing what may look like a benign change, and the code is often so large than many refactoring efforts could not be done by hand.
The more software becomes large and complex, the more testing becomes critical as well.
Those are critical skills for software maintenance and bug fixing, which are a very large portion of software development, and are mostly acquired through experience.
In my experience, new developers are not well-trained for this and are usually quite overwhelmed by large amounts of code, so much that their productivity is very low at first.
I personally find it very difficult to write code on whiteboards (or even paper).
Sorting algorithms are definitely not terribly difficult per se (graph stuff is usually worse, and is still undergraduate level), but it's not a walk in the park either, and can be difficult when it's entirely unexpected and under stress.
By large-scale software development I meant doing software development over large code bases.
It is significantly different to work on a standalone toy project than to work on millions of lines of code with many other people.
brainteasers can be cool though.
Rome still controlled most of Europe for a long time through the Church.
I have hired several, though I use a peculiar screening process.
The company I own works a lot with a public research lab; we often hire people that have demonstrated good skills at internships, postdoctoral or engineer work at the lab.
If there is no one on the job market for the job, you outsource, or you delay the project until you find someone.
Fizzbuzz is not even a test of undergraduate level. More like a test of "do you know a programming language".
This doesn't even take a minute to do, I was talking of actual tests.
Companies that offer higher salaries than the average typically require work that may span several days, and which does indeed have a bit of undergraduate-level stuff in it (data structures and related algorithms, basic parallel programming and synchronization), which has nothing to do with real-world code.
I do not mind doing grunt work if that's useful to the project being developed. Alas, I spend a lot of time doing code refactoring or maintaining the building and testing infrastructure, which is hardly exciting, but necessary.
What I do mind is being evaluated on the quality of my grunt work.
I remember quite a few years ago out of university I applied for a job where they asked me to write a program that returned the i-th number that satisfied a given predicate, with i bounded, with the goal of making the program as fast as possible (the predicate in question had certain analytical properties that were to be used to make the search faster). Since there were few numbers satisfying that predicate within the specified bounds, I just made a program that returned the i-th value in a pre-computed table. In a real world situation, for the problem as phrased, this is clearly the best solution: very short development time, maximum performance. But this is not what the test was for, so I got rejected.
Tests are just stupid. Use real-world experience for evaluation.
You usually need at least 1,000 to 10,000 lines of code to have any idea about the quality of the code you're reviewing.
That doesn't seem like a reasonable amount for an interview.
If you want to review his code prior to the hire, just ask him what open-source projects he's contributed to.
Being good at large-scale software development or at writing robust device drivers will not make you better at doing trivial programming tasks. You must be a clueless manager to think that because someone is a better programmer he can piss code 4 times faster.
The problem lies in the fact that those tests do not highlight your skills at all. Since whether you'll go to next stage of the hire or not depends on how good you did at that test, this is really an issue. The most important thing that decides whether a software developer will choose to work for you is whether he feels valuable and useful to your projects. If you're asking him to do monkey coding, he'll just go look elsewhere.
You only interview people with significant credentials.
If someone has 10 years of experience doing bleeding edge stuff, asking him "can you spend a few days of your time, that is worth $1000/day, to do something trivial and entirely useless for free, just to see if you're at least as good as a college graduate?" is not really a good idea.
It's not like experienced people have problems finding jobs anyway. A student out of university needs to find a job, but someone with experience already has a job, and is usually just scouting to find exciting new projects elsewhere. The difficulty is usually for the company to find really competent people, not the other way around, so they should try to be as nice and attractive as possible.
If you make applicants do demeaning tasks, you're only repelling them.
I only post to Facebook when I do something significant.
I don't want to pollute my wall with trivialities.
Just set your IM status to "at home" or "asleep" instead.
Except your interview only shows he's at the BSc level, which doesn't say much at all.
Would you also like to test if he knows his multiplication tables?
If you want to know whether the CV is true, you can contract a company specialized in verifying background (or have it done by your own HR people). They'll call whatever previous employer he may have had, or verify accountability of whatever company he may have owned. Googling people can also be useful, especially for software-related jobs.
What's relevant is whether the person is a good fit to do what you need him to do.
Testing whether he's good at unrelated basic stuff is indeed irrelevant to whether he has the skills needed for your project.
Of course they can, but you have to understand that people have limited time (since time is money), and since this is ultimately useless because it says nothing about the actual value of the person you want to hire (if you only need him to do that level of things, why not hire someone cheaper instead), the applicant would rather not waste his time with this.
Applicants seek jobs where their particular skills are put to use, so that they can justify asking for high salaries.
A senior software engineer will not be significantly better than a junior one at solving trivial problems.
If you want to evaluate his skill, ask him to do something that's relevant to the added value that's making you hire him in the first place.
I've seen interviewers ask experienced applicants with PhD in various fields of computer science to write the algorithm for quick sort on a whiteboard. Many people can't do it; after all, why would you know by heart an algorithm irrelevant to your domain that you never implement since it's already been done so many times? Even if you remember the principle it's the kind of thing that's difficult to re-code on a whiteboard. Young graduates have a better chance at this, since they just studied it as part of undergraduate computer science class.
It's entirely useless and a waste of everybody's time.