Educating the Headhunters
75 views
Skip to first unread message
mdcra...@gmail.com
Jun 17, 2013, 7:06:25 AM6/17/13
to mobile-...@googlegroups.com
"Throw a bunch of contractor spaghetti at the wall and see what sticks."
-- From alt.computer.consultants.moderated
This isn't directly on-topic for this group, but there are lots of headhunters who post here, looking to place mobile developers.
For most of my career I've avoided working through headhunters, as I and many of my colleagues have had really bad experiences with some of them.
For example my friend Murray made the mistake of listing each of his references on his resume, which he then posted on some job boards. His employer at the time did not know he was looking for new work. The very next day, his manager was hounded with phone calls from headhunters, all of whom wanted to know if this wanted a new job.
On another occasion, a headhunter "edited" Murray's resume so as to score him an on-site interview for a job for which he was completely unqualified. He was scheduled to spend three hours talking one at a time with six different people. They all came to his interview eager to hear more about all his relevant - but completely fictitious - experience. While shocked and angry, Murray is quite polite, honest and professional, so he stayed for the whole three hours to explain the headhunter's subterfuge to all six interviewers.
Commonly I find that headhunters don't have a clue about any of the technologies they expect their candidates to know about. For example, when the very first Microsoft Windows C++ compiler shipped, all the job boards were soon filled with posts seeking candidates who had at least _five_years_ of experience with Microsoft Visual C++, this despite it having been on the market for less than a year.
Job board posts often seek engineers with experience in "C/C++". While there is a significant relationship between C and C++, in reality they are two completely different languages. Quite commonly those who work with just one of the two hate the other with a furious passion. It's also very rare that a particular job actually requires both languages. While one _can_ use both languages in just one program, it's hardly ever done.
Sometimes non-technical hiring managers - the clients - are at fault. I've been programming the Macintosh in all manner of ways since 1986, yet I once spent an entire hour at an interview struggling - unsuccessfully - to convince the hiring manager that I knew how to write applications for Mac OS X. I don't have the first clue why he didn't believe me, but he didn't.
However, not all headhunters and not all hiring managers are that way.
While I avoid most headhunters, there are a few - a *very* few - who are either knowledgeable, professional or just really nice people. During my latest job search since returning to Portland recently, I have been very pleased with most of the headhunters I've dealt with here. Denver Freeman of vtrIT even spent two hours taking me to lunch at Beaches Restaurant, overlooking the Columbia in Vancouver.
This leads me to propose that my objections could be answered were the headhunters to learn more about the technologies they expect us candidates to know.
Back in the day my landlady was the Human Resources Manager for a software company in Santa Cruz, California. She was responsible for hiring software engineers who were good at Object-Oriented Programming. Thus my surprise when she asked me one day to tell her what Object-Oriented Programming actually was. She honestly did not have the first clue.
It's also quite common for candidates to lie on their resumes. I've even heard of highly-placed government officials being discovered by the press to have never graduated from college, despite listing their diplomas on their resumes. Thus my landlady would have been easily duped by a candidate who really didn't know Object-Oriented Programming.
Rather than answering her directly, I had her over to my place, where she sat next to me as I wrote a simple C++ program on my Macintosh, while explaining every step of the way what I was doing.
"CircleToy" was a BeOS program that did nothing other than display a window with a circle drawn in it. That's it. But explaining CircleToy's source code, how it interacted with the rest of the BeOS, and how C++'s take on Object-Orientation compared and contrasted with those of other languages such as Java, all made Object-Oriented Programming quite clear to her.
I still have CircleToy's source, but I decided against posting it as it won't make any sense at all to those who don't already know how to program computers. You'll need my explanations. I'll write something up then post the source and the explanation on my website.
My proposal is to offer presentations - *completely* free of charge - in which I would teach headhunters and recruiters some of the basic concepts that any software engineer should know. The vast majority of the software you'd need to use on your own computers is available completely free of charge, quite commonly as Open Source. While Microsoft Visual C++ costs money, the GNU g++ as well as the clang/llvm C++ compilers are Open Source, therefore available as free downloads.
All I really require is the use of a computer projector and a place to give my presentations. I can supply everything else.
The main Fort Vancouver Public Library has two large projector-equipped meeting rooms that one can use for free if it's for a non-commercial purpose. I spend most of my time at the Backspace Cafe on Fifth and Couch in downtown Portland. Backspace has a projector, but I don't know yet whether one has to pay to use it. If one does, I expect it would be quite cheap if it wasn't on Saturday night.
Another common problem is that there is widespread and quite gross misunderstanding as to what constitutes "experience", as well as how much experience is actually needed to qualify for a job. For example, I've been running Linux since 1994, but with only rare exceptions, I've been running it on my own machines, rather than getting paid by someone else to use Linux. Thus my resume doesn't list much Linux work, leading most recruiters to believe that I am completely unqualified for Linux jobs.
It is very rare for a headhunter to want to know more than how many years one has worked with a given technology. Most programming languages are actually quite simple and quick to learn. What is generally difficult has very little to do with any particular language. Just spending a lot of time writing code in a particular language is unlikely to teach you what you really need to know.
It is very common for even highly experienced engineers to be completely clueless about memory management. Thus I was once asked by a client to look into why his quarter million dollar Sun UltraSparc server kept crashing. It did not take me long at all to determine that it kept running out of swap space. While it _is_ possible for software to handle out-of-memory conditions gracefully, it's not commonly done when writing code that runs on computers that have virtual memory, so most of the processes on his server would crash, eventually taking down the whole machine.
My client did not at first believe that could possibly be the case, as the Java programming language uses "garbage collection" for automated memory management. Sun's Java marketing people had been quite effective at leading non-technical managers into believing that the use of garbage collection meant that one did not need to manage memory. That's not actually the case. While generally easier, it happens all the time that garbage collected code leaks memory. If you keep references to other objects lying around when you don't really need them, you're leaking memory. If you do that repeatedly, you'll use up all your swap space, then not only will your program crash, all the other programs on the system will crash as well.
My short-term solution was to set up a cron job - or scheduled task - that would reboot his server every night. After looking into his existing rat's nest of Java code, my long term solution was to break the bad news that he'd need to rewrite his whole application from scratch. While he was a very good Perl coder, he made the mistake of having a large web application written in Java, without actually knowing anything about Java himself. Thus, when his incompetent Java "engineers" would write bad code, he had no way of knowing the difference.
I was once awakened in the middle of the night by the software engineering manager at a venture-funded started whose eCommerce site went live "Just In Time for Christmas", only to discover that their really high-end Sun server stopped cold under a load of just a few dozen online shoppers. He called me because I'd done some work with the Enhydra Java web application framework. He wanted to know whether I could diagnose performance programs in multithreaded Java programs. In general, such problems are easy to avoid ahead of time, but difficult to fix after all the code has already been written.
I asked him what kind of computers his engineers used to write their own code. Believing that fast computers would make his coders more productive, his company blew a lot of cash on really high-end Sun workstations (~$50,000 apiece or so). No. That's not what you want. My own experience is that I get better results if I use the *slowest* computer that can possibly get the job done. That way performance defects in my own code are more readily apparent to me while I'm still working on the code.
"Did you use a load generator on your application before you went live?" I asked.
"What's a load generator?" the manager asked.
A load generator is automated software that simulates end-user application with the product under test. There are lots of load generators available, for many different applications. For testing his eCommerce app, such a load generator would load one of his pages, find all the links, then simulate clicking each of them by submitting HTTP GET requests, submitting form data and so on.
It was not long at all after that that they went out of business, and not long after that that their website's domain expired. That's pretty sad for a startup that employed dozens of people and had millions of dollars of VC behind it.
In general, managers don't need to know much about writing actual computer program code to do a good job of managing software engineers. I
've had a lot of positive experience with managers who didn't, but were otherwise really good at working with people, with resolving problems, managing budgets, interviewing candidates and the like. But there are some things that non-technical managers do need to know, such as whether the severity and quantity of open bug reports is increasing or decreasing, how many tests are passing or failing, whether the product is fast enough to comply with its specification, whether its consumption of memory, storage space and the like comply as well.
An alternative to attending my talks is to read any of the "Head First" books, published by O'Reilly and Associates (http://www.oreilly.com/). You'll find many of them at the Powells 2 bookstore, on the other side of 10th from the main Powells bookstore. You can read them all online if you subscribe to O'Reilly Safari (https://ssl.safaribooksonline.com/trial). Safari offers a ten book free trial, just nineteen bucks to read ten books per month, as well as an unlimited subscription for $49.00.
Most of O'Reilly's books assume that the reader already knows how to write software, but the Head First books don't. They're targeted at complete Newbies, and so are quite easy to follow.
Tell Me What You Think. I'm All Ears.
Mike Crawford
mdcra...@gmail.com
http://www.goingware.com/
-- From alt.computer.consultants.moderated
This isn't directly on-topic for this group, but there are lots of headhunters who post here, looking to place mobile developers.
For most of my career I've avoided working through headhunters, as I and many of my colleagues have had really bad experiences with some of them.
For example my friend Murray made the mistake of listing each of his references on his resume, which he then posted on some job boards. His employer at the time did not know he was looking for new work. The very next day, his manager was hounded with phone calls from headhunters, all of whom wanted to know if this wanted a new job.
On another occasion, a headhunter "edited" Murray's resume so as to score him an on-site interview for a job for which he was completely unqualified. He was scheduled to spend three hours talking one at a time with six different people. They all came to his interview eager to hear more about all his relevant - but completely fictitious - experience. While shocked and angry, Murray is quite polite, honest and professional, so he stayed for the whole three hours to explain the headhunter's subterfuge to all six interviewers.
Commonly I find that headhunters don't have a clue about any of the technologies they expect their candidates to know about. For example, when the very first Microsoft Windows C++ compiler shipped, all the job boards were soon filled with posts seeking candidates who had at least _five_years_ of experience with Microsoft Visual C++, this despite it having been on the market for less than a year.
Job board posts often seek engineers with experience in "C/C++". While there is a significant relationship between C and C++, in reality they are two completely different languages. Quite commonly those who work with just one of the two hate the other with a furious passion. It's also very rare that a particular job actually requires both languages. While one _can_ use both languages in just one program, it's hardly ever done.
Sometimes non-technical hiring managers - the clients - are at fault. I've been programming the Macintosh in all manner of ways since 1986, yet I once spent an entire hour at an interview struggling - unsuccessfully - to convince the hiring manager that I knew how to write applications for Mac OS X. I don't have the first clue why he didn't believe me, but he didn't.
However, not all headhunters and not all hiring managers are that way.
While I avoid most headhunters, there are a few - a *very* few - who are either knowledgeable, professional or just really nice people. During my latest job search since returning to Portland recently, I have been very pleased with most of the headhunters I've dealt with here. Denver Freeman of vtrIT even spent two hours taking me to lunch at Beaches Restaurant, overlooking the Columbia in Vancouver.
This leads me to propose that my objections could be answered were the headhunters to learn more about the technologies they expect us candidates to know.
Back in the day my landlady was the Human Resources Manager for a software company in Santa Cruz, California. She was responsible for hiring software engineers who were good at Object-Oriented Programming. Thus my surprise when she asked me one day to tell her what Object-Oriented Programming actually was. She honestly did not have the first clue.
It's also quite common for candidates to lie on their resumes. I've even heard of highly-placed government officials being discovered by the press to have never graduated from college, despite listing their diplomas on their resumes. Thus my landlady would have been easily duped by a candidate who really didn't know Object-Oriented Programming.
Rather than answering her directly, I had her over to my place, where she sat next to me as I wrote a simple C++ program on my Macintosh, while explaining every step of the way what I was doing.
"CircleToy" was a BeOS program that did nothing other than display a window with a circle drawn in it. That's it. But explaining CircleToy's source code, how it interacted with the rest of the BeOS, and how C++'s take on Object-Orientation compared and contrasted with those of other languages such as Java, all made Object-Oriented Programming quite clear to her.
I still have CircleToy's source, but I decided against posting it as it won't make any sense at all to those who don't already know how to program computers. You'll need my explanations. I'll write something up then post the source and the explanation on my website.
My proposal is to offer presentations - *completely* free of charge - in which I would teach headhunters and recruiters some of the basic concepts that any software engineer should know. The vast majority of the software you'd need to use on your own computers is available completely free of charge, quite commonly as Open Source. While Microsoft Visual C++ costs money, the GNU g++ as well as the clang/llvm C++ compilers are Open Source, therefore available as free downloads.
All I really require is the use of a computer projector and a place to give my presentations. I can supply everything else.
The main Fort Vancouver Public Library has two large projector-equipped meeting rooms that one can use for free if it's for a non-commercial purpose. I spend most of my time at the Backspace Cafe on Fifth and Couch in downtown Portland. Backspace has a projector, but I don't know yet whether one has to pay to use it. If one does, I expect it would be quite cheap if it wasn't on Saturday night.
Another common problem is that there is widespread and quite gross misunderstanding as to what constitutes "experience", as well as how much experience is actually needed to qualify for a job. For example, I've been running Linux since 1994, but with only rare exceptions, I've been running it on my own machines, rather than getting paid by someone else to use Linux. Thus my resume doesn't list much Linux work, leading most recruiters to believe that I am completely unqualified for Linux jobs.
It is very rare for a headhunter to want to know more than how many years one has worked with a given technology. Most programming languages are actually quite simple and quick to learn. What is generally difficult has very little to do with any particular language. Just spending a lot of time writing code in a particular language is unlikely to teach you what you really need to know.
It is very common for even highly experienced engineers to be completely clueless about memory management. Thus I was once asked by a client to look into why his quarter million dollar Sun UltraSparc server kept crashing. It did not take me long at all to determine that it kept running out of swap space. While it _is_ possible for software to handle out-of-memory conditions gracefully, it's not commonly done when writing code that runs on computers that have virtual memory, so most of the processes on his server would crash, eventually taking down the whole machine.
My client did not at first believe that could possibly be the case, as the Java programming language uses "garbage collection" for automated memory management. Sun's Java marketing people had been quite effective at leading non-technical managers into believing that the use of garbage collection meant that one did not need to manage memory. That's not actually the case. While generally easier, it happens all the time that garbage collected code leaks memory. If you keep references to other objects lying around when you don't really need them, you're leaking memory. If you do that repeatedly, you'll use up all your swap space, then not only will your program crash, all the other programs on the system will crash as well.
My short-term solution was to set up a cron job - or scheduled task - that would reboot his server every night. After looking into his existing rat's nest of Java code, my long term solution was to break the bad news that he'd need to rewrite his whole application from scratch. While he was a very good Perl coder, he made the mistake of having a large web application written in Java, without actually knowing anything about Java himself. Thus, when his incompetent Java "engineers" would write bad code, he had no way of knowing the difference.
I was once awakened in the middle of the night by the software engineering manager at a venture-funded started whose eCommerce site went live "Just In Time for Christmas", only to discover that their really high-end Sun server stopped cold under a load of just a few dozen online shoppers. He called me because I'd done some work with the Enhydra Java web application framework. He wanted to know whether I could diagnose performance programs in multithreaded Java programs. In general, such problems are easy to avoid ahead of time, but difficult to fix after all the code has already been written.
I asked him what kind of computers his engineers used to write their own code. Believing that fast computers would make his coders more productive, his company blew a lot of cash on really high-end Sun workstations (~$50,000 apiece or so). No. That's not what you want. My own experience is that I get better results if I use the *slowest* computer that can possibly get the job done. That way performance defects in my own code are more readily apparent to me while I'm still working on the code.
"Did you use a load generator on your application before you went live?" I asked.
"What's a load generator?" the manager asked.
A load generator is automated software that simulates end-user application with the product under test. There are lots of load generators available, for many different applications. For testing his eCommerce app, such a load generator would load one of his pages, find all the links, then simulate clicking each of them by submitting HTTP GET requests, submitting form data and so on.
It was not long at all after that that they went out of business, and not long after that that their website's domain expired. That's pretty sad for a startup that employed dozens of people and had millions of dollars of VC behind it.
In general, managers don't need to know much about writing actual computer program code to do a good job of managing software engineers. I
've had a lot of positive experience with managers who didn't, but were otherwise really good at working with people, with resolving problems, managing budgets, interviewing candidates and the like. But there are some things that non-technical managers do need to know, such as whether the severity and quantity of open bug reports is increasing or decreasing, how many tests are passing or failing, whether the product is fast enough to comply with its specification, whether its consumption of memory, storage space and the like comply as well.
An alternative to attending my talks is to read any of the "Head First" books, published by O'Reilly and Associates (http://www.oreilly.com/). You'll find many of them at the Powells 2 bookstore, on the other side of 10th from the main Powells bookstore. You can read them all online if you subscribe to O'Reilly Safari (https://ssl.safaribooksonline.com/trial). Safari offers a ten book free trial, just nineteen bucks to read ten books per month, as well as an unlimited subscription for $49.00.
Most of O'Reilly's books assume that the reader already knows how to write software, but the Head First books don't. They're targeted at complete Newbies, and so are quite easy to follow.
Tell Me What You Think. I'm All Ears.
Mike Crawford
mdcra...@gmail.com
http://www.goingware.com/
Matt Harrington (SF)
Jun 17, 2013, 1:33:01 PM6/17/13
to mobile-...@googlegroups.com
One small observation... It’s common for people to think the Microsoft compilers cost money. However, they’re actually free. For example, here are the compilers for Windows 8 apps: http://aka.ms/downloadvs2012.
Think of it as a freemium business model. The base product is given away for free. More advanced features are available for purchase.
Matt
Brent
Jun 18, 2013, 9:49:57 AM6/18/13
to mobile-...@googlegroups.com
Hi Mike -
I like your problem with a solution approach. It's very generous of you to offer to educate the uneducated which would help many others. Thanks.
Speaking of load-testing, I was unable to get your site to come up. http://www.goingware.com/
Possibly a glitch in the Matrix? Probably more like a DNS issue?
cheers,
brent
Reply all
Reply to author
Forward
0 new messages