Your Résumé vs. Oblivion (Companies Resort to Software to Sift Job Applications for Right Skills)

Many job seekers have long suspected their online employment applications disappear into a black hole, never to be seen again. Their fears may not be far off the mark, as more companies rely on technology to winnow out less-qualified candidates.

Recruiters and hiring managers are overwhelmed by the volume of résumés pouring in, thanks to the weak job market and new tools that let applicants apply for a job with as little as one mouse click. The professional networking website LinkedIn recently introduced an "apply now" button on its job postings that sends the data in a job seeker's profile directly to a potential employer.

While job boards and networking websites help companies broadcast openings to a wide audience, potentially increasing the chance the perfect candidate will reply, the resulting flood of applications tends to include a lot of duds. Most recruiters report that at least 50% of job hunters don't possess the basic qualifications for the jobs they are pursuing.

To cut through the clutter, many large and midsize companies have turned to applicant-tracking systems to search résumés for the right skills and experience. The systems, which can cost from $5,000 to millions of dollars, are efficient, but not foolproof.

Ed Struzik, an International Business Machines Corp. expert on the systems, puts the proportion of large companies using them in the "high 90%" range, and says it would "be very rare to find a Fortune 500 company without one.

Depends on what the employer is looking for. I work on a product that comes with lots of parts, it takes a good 6 months of working with it to become competent in a large enough portion to be useful (ancient products are so fun), and that’s in any job title from support to dev. When you’ve got entry learning curve you want people to stick around. A “normal” 1 year consultant gig means that just about the time the person is really starting to contribute they’re looking for their next gig. We want employees, long term employees. The entire engineering team has been here at least 5 years, got a few members past 15. We have no interest in consultants, it’s not our model. Not that they’re bad, they just won’t work here.

Depends on what the employer is looking for. I work on a product that comes with lots of parts, it takes a good 6 months of working with it to become competent in a large enough portion to be useful

How about new development where it takes six months just to understand the requirements? If you want someone who can do that, your best bet is to look for someone who's done it before.

1 year consultant gig means that just about the time the person is really starting to contribute they’re looking for their next gig. We want employees, long term employees. The entire engineering team has been here at least 5 years, got a few members past 15. We have no interest in consultants, it’s not our model. Not that they’re bad, they just won’t work here.

My guess is that you've never tried. Either that or all you want is good little mind numbed robots who won't object to watching sexual harassment videos once a month. Real consultants never abandon their customers after one year, or ten.

ML/NJ

Nobody here is a mind numbed robot, we don’t watch harassment videos ever. And I never said anything about abandonment. Consultants are around less than employees, even if they’re still around there’s always some other gig. This is life cycle software we’re working on, when we finish one version we start on the next. When I got here we were halfway through 8.5, now we’re halfway through 10.5 in between we’ve done 5 release versions and a bunch of feature packs and a bunch more service packs. The day after we have the ship party for 10.5 we’ll start in on the first service pack to fix those last minute bugs, meanwhile management will be finishing plans for the next release, then we get trucking. It’s not a consultant environment, it’s an employee environment. Nothing wrong with consultants, but each tool has its purpose, they’re phillips heads and we’re a slot head environment. Consultants are great for projects that have end dates that slide into maintenance mode. We don’t have end dates. We have label change dates, new code name, new release version, same damn product.

All software has bugs.

Speak for yourself. And we'll all be glad you don't write stuff for airplanes or missiles.

Being proud of shipping stuff with bugs because it generates revenue isn't something I'd crow about.

I do mostly embedded stuff. But I did write a Windows program (Mazemaker) which Brian Livingston included in one of his Windows Secrets books. So far as I am aware, no one ever encountered a bug once I released the program.

ML/NJ

Hey there’s a reason I didn’t go to work on software that moves metal or runs medicine. But I have friends that do, and you know what? Their software has bugs too.

I’m a realist. Nothing that has a million parts is without flaws. Even before software got put on them every plane in the air has issues. I know folks that worked on flight lines, both mechanics and pilots, part of check out on a plane is the mechanic giving the pilot the list of stuff that’s broken on the plane. It’s the nature of the world.

The question isn’t does your software have bugs, the question is how likely are they to be encountered and what happens when they are. There’s a secret combination of button clicks I can do to our client app that will crash it hard enough you need to uninstall it. It’s been in there for 6 years, nobody out in the field has ever run into it as far as we know. Largely because that secret combination involves over 100 different steps, including multiple openings and closings of the app. A bug for sure, but nobody is gonna hit it.

Less than 1% of our tech support calls result in bugs being written. When we got bought the company that bought us wouldn’t believe that. They considered 20% to be the target. They actually came down and “helped” us rerun the reports. Am I proud of our software? Hell yeah. I’m especially proud of the section I primarily work on which tech support considers a great achievement to get a bug against. But I’m not stupid. I know bugs get through, I just try to make sure those bugs are outside the normal usage so the customers don’t hit them. We aren’t moving metal, we aren’t giving medicine, we don’t need to be bullet proof. And our software is a hell of a lot more complex than any embedded system, which has bugs I can absolutely guarantee.

There’s a secret combination of button clicks I can do to our client app that will crash it hard enough you need to uninstall it. It’s been in there for 6 years, nobody out in the field has ever run into it as far as we know. Largely because that secret combination involves over 100 different steps, including multiple openings and closings of the app. A bug for sure, but nobody is gonna hit it.

And you just left it there?

Shame!

Oooooh. A hundred steps? Like that's a lot for a computer? You would have been a hoot on antenna tracking system I did for geosynchronous satellites (which aren't truly geosynchronous which is why they need to be tracked). Who could test the thing for a hundred days? And how many of those days would be subject to rain fades? Guess what? You simulate the inputs to a system like that so you can stress the piss out of it until it fails. It will either fail (or degrade) in reasonable ways or surprising ways. If you don't get rid of all of the surprises you're not being fair to your customer.

ML/NJ

It’s been there for 6 years and nobody has run into it. Reproducing it takes half an hour by hand, 10 minutes with an automation script. 100 steps is a lot, because to get the bug you have to do those steps in that order, do one thing different no crash. In the time it would have taken to find and solve that bug we instead found and solved probably 100 other bugs, bugs the customer was actually likely to run into, as opposed to an obscure series of actions that a user will never do.

Again there’s the difference between moving metal and not. This is communication software. Even if a customer did run into that bug (which again, 6 years and thousands of customers with 10s of thousands of users using the thick client have not) nobody is gonna die. You’re failing to grasp the difference between large customer base wide open usage software and limited user base limited input life of embedded systems. The day you make a package that integrates with every piece of non-game software MS makes AND Lotus Note, AND 4 different brands of MFP AND two of Sharepoint’s competitors in document management AND do make a new release for the thing every year AND have no bugs you have room to talk. Until then you’re just blowing smoke and telling lies.

Until then you’re just blowing smoke and telling lies.

Put your money where your mouth is Pal. I can provide multiple witnesses for whatever I've said here. (And not just here either. Anywhere.)

Go ahead, You get by with your sloppy work. I never said you were the only one. But that approach doesn't cut it with me.

ML/NJ

i’ve also heard, cut and paste the job description into a white font (making it invisible to the eye) on the bottom of your resume. it will not show up, but the software will still read the key words and not bump the resume. not sure if it works.

That's an old SEO trick from about 2000. Doesn't work anymore. Google doesn't like search engine spammers.

I believe fully in what you said. I also understand the difference between making embedded systems where there’s a good chance your code will never interact with a human and application software. Embedded system guys are always so cocky because they work in a nice safe area, I’d love to see how your code works out here in the real world. Out here in application land 99% of your code is error handling because 99% of the input you get from the user is flawed. This is where the bugs live. Life is easy when you get all your input from a radar dish, try getting your input from people that can’t even type their own names.

There’s nothing sloppy in my work at all. Funny how important it is to you that everybody else is wrong. How you keep throwing insults. Just another embedded system guy thinking his #$%^ don’t stink. I’ll pay attention to your “approach” when you’re out in the application layer where things get hard. That’s where your big lies are, thinking that where you write code has any relationship to my world. You’re swimming in the wading pool. I’m out here in the ocean with bad use input and complex environments. It’s a whole different world when you have to assume your code is being used wrong.

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.