In a surprisingly candid revelation today, Google admitted that their spidering engines are actually intended to find links to web sites and that these links will be shown on Google.com.
I think what you are describing is a mismatch in expectations. Google software engineers develop code. With few exceptions, they don't present to customers (that's a sales engineer's job) and they don't define requirements (that's a product manager's job.) It is a waste of time for a Google software engineer to do those things - it's literally not their job, as defined by the corporate job description for software engineers.
If you want someone who can implement advanced algorithms, code like crazy, and build distributed systems - that's when you want a Google software engineer.
I'm a current Google employee who *can* do requirements and customer presentations - and those skills haven't been useful here.
Your description of Netscape being "backstabbed" appears to conveniently forget that Netscape didn't ship anything useful for for FIVE YEARS. As stated by Wikipedia (http://en.wikipedia.org/wiki/Netscape#Netscape_Communicator_.28versions_4.0.E2.80.934.8.29): Netscape released the final version of Netscape Communicator [4.x] in June 1997. Netscape 6 was not yet ready for release and it flopped badly Netscape 7.0 (based on Mozilla 1.0.1) was released in August 2002
If you have enterprise customers, then make the changelog available under NDA. Or just email it to key customers that ask, so that prospective customers never see it.
You think you're fighting manager's lack of understanding of software development. You are wrong.
You are fighting politically savvy people who have found a way to blame you for their problems. They don't want you to solve the problem and will actively work to prevent you from solving the problem, because then you can't be the scapegoat.
If you don't have a VP or C-level manager who will fight this fight for you, then you've already lost. Don't bang your head against the wall. Play the same game as everyone else and find someone else that you can use as a scapegoat. Meanwhile, start looking for a new job.
Even if you miraculously "fix" this problem, someone else is going to claim credit and you're going to get nothing.
To all those people who pooh-pooh the "simple" questions - you are missing all of the fun. If you keep up with current literature, you answer those questions with sophisticated answers that go over the interviewer's head. Here are some example:
- You can describe how to multithread across multiple cores and then coalesce the result set. Bonus points for referring to Google's MapReduce paper. - You can use functional programming and describe why an in-place, memory-saving result is a bad idea on modern processors because it's hard to parallelize. Bonus points for discussing cache contention issues across processors. - Many string manipulation questions can be answered in exotic ways with vector instructions like SSE (Streaming SIMD). Most interviewers say you can use any language, so picking a mixed C/assembly approach completely blows their mind. Bonus points for describing why you need a particular version of SSE for better performance. - And if all else fails, discussing x86 L1/L2 cache locality is a sure way to go over their heads. You can use this for nearly any data structures question. Bonus points for discussing pipeline stalls due to cache misses.
So my goal is to make sure that the interviewer understands that they don't remotely understand the problem as well as I do, even for a very "simple" question. It's highly entertaining to watch the interviewers squirm by asking them questions to see if they are keeping up with you:-)
And yes, this interview strategy has worked well. It's gotten me job offers from the two best companies I've worked at.
Because an incredible percentage of products get canceled and the marketing people have learned not to waste their time on some shiny new idea that's probably going to get canceled anyway. Wait a few months and see if the project survives and it's worth investing your time, because if you touch/interact with a project and it's canceled, that of course makes you look bad and has wasted your time. There's the additional benefit that, if the developers are late, that gives you a scapegoat if your marketing campaign isn't ready. And if the developers waste a million dollars redesigning and making changes, it's not your budget and your promotion doesn't depend on helping other departments save money.
So basically the whole corporate culture exists to make sure that developers can't get meaningful feedback in a timely manner.
And that's how everything works in a moderately well-run organization. A dysfunctional organization is much, much worse.
You really don't seem to understand science at all. You don't "believe" in scientific theories. Evolution is a theory, not a fact. A theory is a "system of ideas intended to explain something" As such, evolution is the best scientific system put together that explains our observations of the world. It's not perfect, but very few theories are perfect. Even in pure mathematics there are contradictions and holes.
If you refuse to accept the usefulness of evolution to explain the world, then you should similarly refuse to teach any scientific theory, which would make for extremely incompetent engineers.
There's hundreds of millions of people using Cox, Gmail, Comcast and numerous of other services that have thousands of employees who have access to your mailbox at any time. You aren't "safe" because you use some commercial service. And let's not even talk about the intermediate nodes that your traffic can get routed through, some of whom have government requirements to log your email whether you know it or not.
Personally, I'd trust someone with whom I had a longtime connection a lot more than I'd trust the average large company.
Get a whiteboard. Put your task list on it, in priority order, with time estimates. Order should be based on a business decision - what's the financial risk of something failing. Backups and security are always pretty high on my list.
Get buy-in from management on the ordering, because when something breaks (and it will), you need to make sure that someone above you approved the risk ordering.
Once you have a priority order, then figure out how much it's going to cost to do each one. If mgmt considers something a #1 priorty and is only willing to fund 10% of the price to fix it, then you have a pretty clear warning that it's time to look for a new job.
When tasks are finished, cross them off but don't erase. Make sure everyone knows that things are getting done.
Don't let anyone rearrange the task ordering without a financial justification that's approved by mgmt.
You think that's pretty funny, don't you? I say it's pathetic and I hope your karma catches up to you in a big way. I talk to those AOL customers every day. Many of them are senior citizens. On average, they aren't well educated, and they don't have a lot of money. For some of them, $25 a month is a lot of money. So while you laugh your way to the bank with your paycheck, your health insurance, and all of the other benefits, remember that the people you are screwing are the ones that funded that paycheck, and the reason they are so angry in the first place is because of the way they've been treated by AOL customer service reps.
The contract (or simply the "agreement") will make or break you. I've estimated, negotiated, and developed for jobs ranging from a few hundred dollars to multiple millions, from a handshake to a 40 page contract. Writing a good proposal, knowing what to charge for, knowing what to negotiate, knowing when to hold your line - these are things it takes years to learn (and many people never do.)
So do yourself a big favor that will certainly increase your profit and may keep you out of court. Get involved with other consultants and learn everything you can. Find a small business group and take classes. Go talk to SCORE - their services are free. See if there is a web developers group near you on meetup.com.
In short, find mentors - people who have already learned from the school of hard knocks and are willing to share their experience.
Just one "simple" example - how much to charge. There's an absolute minimum you must charge just to break even. You have to factor in expenses (including software upgrades), capital costs (computer equipment), vacations, overhead, business insurance, attorneys, CPA, marketing, non-billable time - the list goes on. If you don't know how to do these calculations, then get help before you go broke.
The solution to this is obvious. If PGP encryption is required on all drives, fine. Just order 500GB of RAM and only use the drive for backup. That's only about US$6000 at today's prices. Cheap;-)
You are making the opposite mistake of the web design firms. The web design firms said "I have no idea what you are talking about." You basically said "this is hard and will be expensive." Both of you fail in the consulting world.
The correct question is "what can I do for a price that makes sense for the customer's budget?"
Despite the complexity of Section 508, there are several checklists on the web that get you started with the obvious stuff. For a small web site with a small budget, this is the right place to start. It doesn't take PhD to find these lists with Google.
The last web site project I outsourced had accessibility as one of the requirements. For Section 508 tasks that could be done by simply designing the site correctly the first time, my client was willing to pay.
Not a single web design agency we talked to had any idea what we were talking about. One of them wanted to charge us $1200 for a day of work so they could "research it."
So it's not just Pointy Haired Bosses that are causing the problem.
As a (former) hiring manager in the C++ world, the people who I always gave a second look were the ones who had developed an application on their own, finished the software, and got a few people to use it. It didn't have to be perfect, it didn't have to be fancy, but it showed that you had the perseverance to finish a job and the skill to do it on your own. Even games were within scope.
Having written such software, you can have a much more interesting interview than the standard Algorithms 101 interview where you are asked to "write a function that reverses a string."
In any case, be very careful with maintenance jobs. Don't get stuck working on out of date languages or products (C, Visual Basic 6, and PowerBuilder, for example.) The first technology you put on your resume can start you on a track that can be hard to change.
I think you mean a PDP-11. I spent several years developing on a PDP-8. No C compiler was ever built for it, much less a C++ compiler. Even so, your comment still doesn't make sense. The PDP-11 is the granddaddy of today's hardware - multiple registers, stack, protected memory, etc. Today's hardware has all sorts of extra toys, but programmatically it's not that different than a PDP-11. (Yes, I've done assembly language development on a PDP-8, PDP-11, 68000, 808x, and Pentium, among others.) OTOH, the PDP-8 had a 12-bit word, had a single register, no stack, and a rather painful page memory architecture. Anyone else remember what TAD indirect does?
In spite of that, I'm not sure what you are alluding to in your first paragraph. It's pretty unlikely that anyone is going to start writing console games in Perl, Python, PHP, Haskell, VB.net, or (shudder) Java. There's one thing that C and C++ are good at, and that's going fast.
I guess it depends on what you do. I own a company and have an archive of years of customer proposals, design documents, financial information, etc. All in all, thousands and thousands of documents. Creating a taxonomony of documents (which is what you describe) is pretty straightforward on a small scale, but when you work at a corporate level, it becomes almost impossible. For example, should a customer-requested design change be filed under product design, customer correspondence, contracts, or finance?
In all likelihood, for a single customer request, I'd have documents filed in all of those directories. With an indexing system, I can search on the change request number and have the complete list of documents in about two seconds. The index also includes any email correspondence about the change request. I can't even navigate to my "Documents" folder in two seconds, much less browse to four different filesystem folders as well as the appropriate folder in my email. I do this many times per day, all of which add up to a significant time savings.
On the other end of the spectrum, many users save *everything* in their "Documents" folder. They don't know how to create a new folder in Windows, must less use filenames that will still be meaningful in two years. For those users, an index is the only way they'll ever find documents again.
Just ask any gmail-lover why search is better than folders. (Personally, I use a combination, but that's another story.)
It's unfortunate that you've been modded to 5 because your performance recommendations might be useful for a games-oriented computer, but they'll badly hurt the performance of a mixed-use Vista system.
I'll start with "free memory". Vista's memory handling is similar to Linux - free memory is kept to an absolute minimum in the interest of keeping as much as possible in memory. Just because free memory is low doesn't mean "available" memory is low. Any memory used by SuperFetch is available for reuse at any time, it just doesn't show as "free." SuperFetch is the magic that makes Word and Visual Studio open almost instantly. Turning off SuperFetch will KILL your performance. All work done by SuperFetch is done as low priority I/O and has minimal impact on running apps.
Turning off Volume Shadow Copy may save a little disk activity (very little), but if you turn off Volume Shadow Copy you'll lose the ability to roll the system back if you install a bum driver. Really, really bad idea. (Note that VSS has existed on XP for years and I've never heard anyone complain about it there.) Turning off VSS is about as smart as taking the batteries out of your smoke detector.
Indexing service does cause a lot of disk thrashing, but (like SuperFetch) it's done with low priority I/O. Running indexing on XP could absolutely kill your system. Running it on Vista is pretty much a non-issue unless you are memory constrained. Unless you have a photographic memory and know where all of your documents are, you won't be saving much time if you are manually searching for your documents.
If you are having that much trouble with performance, spend $50 and buy yourself another Gig of RAM. Vista runs fantastically well with 2GB RAM.
This isn't a question about speed, this is a risk analysis question. Is is riskier to allow the bug to stay or riskier to run code that didn't go through a full QA cycle? At the end of the day, that's the customer's decision, not yours. It's your company's job to communicate the risks to the customer.
Having said that, I'd say that getting a build out in 48 hours shouldn't be hard. If you have proper source control and proper build procedures, you should be able to reliably rebuild the last version of your product with absolute certainty. If you have a one line change that has been code reviewed by other senior developers, you should be able to create a point release and still sleep soundly at night. (Disclaimer: ignore his paragraph for software that human lives depend on such as space vehicles, medical devices, etc.)
I've never heard of Base One, and I never would have guessed from their home page http://www.base-one.com/ that they could do what they did, but that has to be one of the more impressive "code reviews" I've seen. The code review encompasses hardware, software, testing, architecture, design - in short, a rather thorough analysis. Seeing all of those skills come together for an embedded system project is pretty impressive. (Consider that, at Draeger, it appears that almost none of those skills were bought to bear...)
Actually, you are quite correct about the intelligent person versus the "idiot." Take a look at this article from the Journal of Personality and Social Psychology, titled "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments":
Slashdot Mirror
"Google Admits that Google.com Contains Links"
In a surprisingly candid revelation today, Google admitted that their spidering engines are actually intended to find links to web sites and that these links will be shown on Google.com.
I think what you are describing is a mismatch in expectations. Google software engineers develop code. With few exceptions, they don't present to customers (that's a sales engineer's job) and they don't define requirements (that's a product manager's job.) It is a waste of time for a Google software engineer to do those things - it's literally not their job, as defined by the corporate job description for software engineers.
If you want someone who can implement advanced algorithms, code like crazy, and build distributed systems - that's when you want a Google software engineer.
I'm a current Google employee who *can* do requirements and customer presentations - and those skills haven't been useful here.
Your description of Netscape being "backstabbed" appears to conveniently forget that Netscape didn't ship anything useful for for FIVE YEARS. As stated by Wikipedia (http://en.wikipedia.org/wiki/Netscape#Netscape_Communicator_.28versions_4.0.E2.80.934.8.29):
Netscape released the final version of Netscape Communicator [4.x] in June 1997.
Netscape 6 was not yet ready for release and it flopped badly
Netscape 7.0 (based on Mozilla 1.0.1) was released in August 2002
If you have enterprise customers, then make the changelog available under NDA. Or just email it to key customers that ask, so that prospective customers never see it.
You think you're fighting manager's lack of understanding of software development. You are wrong.
You are fighting politically savvy people who have found a way to blame you for their problems. They don't want you to solve the problem and will actively work to prevent you from solving the problem, because then you can't be the scapegoat.
If you don't have a VP or C-level manager who will fight this fight for you, then you've already lost. Don't bang your head against the wall. Play the same game as everyone else and find someone else that you can use as a scapegoat. Meanwhile, start looking for a new job.
Even if you miraculously "fix" this problem, someone else is going to claim credit and you're going to get nothing.
To all those people who pooh-pooh the "simple" questions - you are missing all of the fun. If you keep up with current literature, you answer those questions with sophisticated answers that go over the interviewer's head. Here are some example:
- You can describe how to multithread across multiple cores and then coalesce the result set. Bonus points for referring to Google's MapReduce paper.
- You can use functional programming and describe why an in-place, memory-saving result is a bad idea on modern processors because it's hard to parallelize. Bonus points for discussing cache contention issues across processors.
- Many string manipulation questions can be answered in exotic ways with vector instructions like SSE (Streaming SIMD). Most interviewers say you can use any language, so picking a mixed C/assembly approach completely blows their mind. Bonus points for describing why you need a particular version of SSE for better performance.
- And if all else fails, discussing x86 L1/L2 cache locality is a sure way to go over their heads. You can use this for nearly any data structures question. Bonus points for discussing pipeline stalls due to cache misses.
So my goal is to make sure that the interviewer understands that they don't remotely understand the problem as well as I do, even for a very "simple" question. It's highly entertaining to watch the interviewers squirm by asking them questions to see if they are keeping up with you :-)
And yes, this interview strategy has worked well. It's gotten me job offers from the two best companies I've worked at.
Because an incredible percentage of products get canceled and the marketing people have learned not to waste their time on some shiny new idea that's probably going to get canceled anyway. Wait a few months and see if the project survives and it's worth investing your time, because if you touch/interact with a project and it's canceled, that of course makes you look bad and has wasted your time. There's the additional benefit that, if the developers are late, that gives you a scapegoat if your marketing campaign isn't ready. And if the developers waste a million dollars redesigning and making changes, it's not your budget and your promotion doesn't depend on helping other departments save money.
So basically the whole corporate culture exists to make sure that developers can't get meaningful feedback in a timely manner.
And that's how everything works in a moderately well-run organization. A dysfunctional organization is much, much worse.
You really don't seem to understand science at all. You don't "believe" in scientific theories. Evolution is a theory, not a fact. A theory is a "system of ideas intended to explain something" As such, evolution is the best scientific system put together that explains our observations of the world. It's not perfect, but very few theories are perfect. Even in pure mathematics there are contradictions and holes.
If you refuse to accept the usefulness of evolution to explain the world, then you should similarly refuse to teach any scientific theory, which would make for extremely incompetent engineers.
There's hundreds of millions of people using Cox, Gmail, Comcast and numerous of other services that have thousands of employees who have access to your mailbox at any time. You aren't "safe" because you use some commercial service. And let's not even talk about the intermediate nodes that your traffic can get routed through, some of whom have government requirements to log your email whether you know it or not.
Personally, I'd trust someone with whom I had a longtime connection a lot more than I'd trust the average large company.
Require the buyer to forward all of your email addresses for 24 months. Help the person set up the forwarding if they don't know how to do it.
Get a whiteboard. Put your task list on it, in priority order, with time estimates. Order should be based on a business decision - what's the financial risk of something failing. Backups and security are always pretty high on my list.
Get buy-in from management on the ordering, because when something breaks (and it will), you need to make sure that someone above you approved the risk ordering.
Once you have a priority order, then figure out how much it's going to cost to do each one. If mgmt considers something a #1 priorty and is only willing to fund 10% of the price to fix it, then you have a pretty clear warning that it's time to look for a new job.
When tasks are finished, cross them off but don't erase. Make sure everyone knows that things are getting done.
Don't let anyone rearrange the task ordering without a financial justification that's approved by mgmt.
You think that's pretty funny, don't you? I say it's pathetic and I hope your karma catches up to you in a big way. I talk to those AOL customers every day. Many of them are senior citizens. On average, they aren't well educated, and they don't have a lot of money. For some of them, $25 a month is a lot of money. So while you laugh your way to the bank with your paycheck, your health insurance, and all of the other benefits, remember that the people you are screwing are the ones that funded that paycheck, and the reason they are so angry in the first place is because of the way they've been treated by AOL customer service reps.
Your friend should use RAID 10 floppies to safeguard his data and to improve access speed.
A floppy SAN may be the perfect solution if multiple people need access.
The contract (or simply the "agreement") will make or break you. I've estimated, negotiated, and developed for jobs ranging from a few hundred dollars to multiple millions, from a handshake to a 40 page contract. Writing a good proposal, knowing what to charge for, knowing what to negotiate, knowing when to hold your line - these are things it takes years to learn (and many people never do.)
So do yourself a big favor that will certainly increase your profit and may keep you out of court. Get involved with other consultants and learn everything you can. Find a small business group and take classes. Go talk to SCORE - their services are free. See if there is a web developers group near you on meetup.com.
In short, find mentors - people who have already learned from the school of hard knocks and are willing to share their experience.
Just one "simple" example - how much to charge. There's an absolute minimum you must charge just to break even. You have to factor in expenses (including software upgrades), capital costs (computer equipment), vacations, overhead, business insurance, attorneys, CPA, marketing, non-billable time - the list goes on. If you don't know how to do these calculations, then get help before you go broke.
The solution to this is obvious. If PGP encryption is required on all drives, fine. Just order 500GB of RAM and only use the drive for backup. That's only about US$6000 at today's prices. Cheap ;-)
You are making the opposite mistake of the web design firms. The web design firms said "I have no idea what you are talking about." You basically said "this is hard and will be expensive." Both of you fail in the consulting world.
The correct question is "what can I do for a price that makes sense for the customer's budget?"
Despite the complexity of Section 508, there are several checklists on the web that get you started with the obvious stuff. For a small web site with a small budget, this is the right place to start. It doesn't take PhD to find these lists with Google.
The last web site project I outsourced had accessibility as one of the requirements. For Section 508 tasks that could be done by simply designing the site correctly the first time, my client was willing to pay.
Not a single web design agency we talked to had any idea what we were talking about. One of them wanted to charge us $1200 for a day of work so they could "research it."
So it's not just Pointy Haired Bosses that are causing the problem.
As a (former) hiring manager in the C++ world, the people who I always gave a second look were the ones who had developed an application on their own, finished the software, and got a few people to use it. It didn't have to be perfect, it didn't have to be fancy, but it showed that you had the perseverance to finish a job and the skill to do it on your own. Even games were within scope.
Having written such software, you can have a much more interesting interview than the standard Algorithms 101 interview where you are asked to "write a function that reverses a string."
In any case, be very careful with maintenance jobs. Don't get stuck working on out of date languages or products (C, Visual Basic 6, and PowerBuilder, for example.) The first technology you put on your resume can start you on a track that can be hard to change.
I think you mean a PDP-11. I spent several years developing on a PDP-8. No C compiler was ever built for it, much less a C++ compiler. Even so, your comment still doesn't make sense. The PDP-11 is the granddaddy of today's hardware - multiple registers, stack, protected memory, etc. Today's hardware has all sorts of extra toys, but programmatically it's not that different than a PDP-11. (Yes, I've done assembly language development on a PDP-8, PDP-11, 68000, 808x, and Pentium, among others.) OTOH, the PDP-8 had a 12-bit word, had a single register, no stack, and a rather painful page memory architecture. Anyone else remember what TAD indirect does?
In spite of that, I'm not sure what you are alluding to in your first paragraph. It's pretty unlikely that anyone is going to start writing console games in Perl, Python, PHP, Haskell, VB.net, or (shudder) Java. There's one thing that C and C++ are good at, and that's going fast.
Jack of All Trades. Master of None.
I think the same of Visual Studio.
I guess it depends on what you do. I own a company and have an archive of years of customer proposals, design documents, financial information, etc. All in all, thousands and thousands of documents. Creating a taxonomony of documents (which is what you describe) is pretty straightforward on a small scale, but when you work at a corporate level, it becomes almost impossible. For example, should a customer-requested design change be filed under product design, customer correspondence, contracts, or finance?
In all likelihood, for a single customer request, I'd have documents filed in all of those directories. With an indexing system, I can search on the change request number and have the complete list of documents in about two seconds. The index also includes any email correspondence about the change request. I can't even navigate to my "Documents" folder in two seconds, much less browse to four different filesystem folders as well as the appropriate folder in my email. I do this many times per day, all of which add up to a significant time savings.
On the other end of the spectrum, many users save *everything* in their "Documents" folder. They don't know how to create a new folder in Windows, must less use filenames that will still be meaningful in two years. For those users, an index is the only way they'll ever find documents again.
Just ask any gmail-lover why search is better than folders. (Personally, I use a combination, but that's another story.)
It's unfortunate that you've been modded to 5 because your performance recommendations might be useful for a games-oriented computer, but they'll badly hurt the performance of a mixed-use Vista system.
I'll start with "free memory". Vista's memory handling is similar to Linux - free memory is kept to an absolute minimum in the interest of keeping as much as possible in memory. Just because free memory is low doesn't mean "available" memory is low. Any memory used by SuperFetch is available for reuse at any time, it just doesn't show as "free." SuperFetch is the magic that makes Word and Visual Studio open almost instantly. Turning off SuperFetch will KILL your performance. All work done by SuperFetch is done as low priority I/O and has minimal impact on running apps.
Turning off Volume Shadow Copy may save a little disk activity (very little), but if you turn off Volume Shadow Copy you'll lose the ability to roll the system back if you install a bum driver. Really, really bad idea. (Note that VSS has existed on XP for years and I've never heard anyone complain about it there.) Turning off VSS is about as smart as taking the batteries out of your smoke detector.
Indexing service does cause a lot of disk thrashing, but (like SuperFetch) it's done with low priority I/O. Running indexing on XP could absolutely kill your system. Running it on Vista is pretty much a non-issue unless you are memory constrained. Unless you have a photographic memory and know where all of your documents are, you won't be saving much time if you are manually searching for your documents.
If you are having that much trouble with performance, spend $50 and buy yourself another Gig of RAM. Vista runs fantastically well with 2GB RAM.
This isn't a question about speed, this is a risk analysis question. Is is riskier to allow the bug to stay or riskier to run code that didn't go through a full QA cycle? At the end of the day, that's the customer's decision, not yours. It's your company's job to communicate the risks to the customer.
Having said that, I'd say that getting a build out in 48 hours shouldn't be hard. If you have proper source control and proper build procedures, you should be able to reliably rebuild the last version of your product with absolute certainty. If you have a one line change that has been code reviewed by other senior developers, you should be able to create a point release and still sleep soundly at night. (Disclaimer: ignore his paragraph for software that human lives depend on such as space vehicles, medical devices, etc.)
I've never heard of Base One, and I never would have guessed from their home page http://www.base-one.com/ that they could do what they did, but that has to be one of the more impressive "code reviews" I've seen. The code review encompasses hardware, software, testing, architecture, design - in short, a rather thorough analysis. Seeing all of those skills come together for an embedded system project is pretty impressive. (Consider that, at Draeger, it appears that almost none of those skills were bought to bear...)
So kudos to Base One. Great work.
Actually, you are quite correct about the intelligent person versus the "idiot." Take a look at this article from the Journal of Personality and Social Psychology, titled "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments":
d f
http://www.apa.org/journals/features/psp7761121.p