What should a job-seeker know about job non-descriptions?

Question

I completed a phone screen that sounded somewhere between front-end web developer and "code monkey"; core competencies listed include HTML, CSS, jQuery, and some responsive design. (Note to those not particularly connected to web development: these are pretty much technologies expected of almost anyone doing that kind of work. "Our shop's preferred specialties" technologies tend to be more like you can see showcased at TodoMVC.com)

This may just be a sign the role was junior, but two subsequent paragraphs of the job description were:

RESPONSIBILITIES: Accountable for developing software code and associated life cycle deliverables for PC and Mainframe applications. Interprets process, data modules, and business requirements into software code. Analyzes, designs, develops, implements and maintains moderate to complex computer programs and subsystems. Performs all of the steps required to design, test, and code such programs. Develops procedures and operating instructions, and successfully moves programs into production. Provides production support through problems analysis and resolution to correct deficiencies. Performs assignments under direct supervision.

COMPETENCIES: Analyze problem or new request; design problem or new request resolution; familiar with SDLC methodologies; develop program specifications; design testing requirements; code modules according to specifications and client standards; prepare test plan and test modules; develop program and system documentation; conduct program and system implementation; maintain application production environment; respond and resolve production problems; and respond and resolve user inquiries.

I have difficulty reading much more in this beyond "the decision was made to copy and paste boilerplate copy."

Is there anything more to take besides this being a junior position and they don't have enough invested in it to consider it particularly important to write a useful job description?

Answer 1

I have difficulty reading much more in this beyond "the decision was made to copy and paste boilerplate copy."

Is there anything more to take besides this being a junior position and they don't have enough invested in it to consider it particularly important to write a useful job description?

It's possible that they simply copied another job description and didn't tailor it adequately.

It's possible they didn't put much effort into the job description because this is just a junior position. But for me, even junior positions are worth creating relevant descriptions.

It's more likely that they just aren't very good at creating written job descriptions. Many hiring managers aren't good at that task.

And for some reason, few companies do a great job of training their hiring managers in the process of writing job descriptions, interviewing, negotiating, and writing job offers. I don't really understand why, since these are rather important tasks.

Answer 2

I'd likely look at this the other way. Some places can be very specific about what a developer will do where other tasks may be taken by different departments, e.g. there may be business analysts to gather requirements, system administrators to deploy solutions, quality assurance analysts to check for defects, where in the position you describe this could all be done by the same person which can be an important distinction. Some people may want to be a generalist that handles everything from figuring out what to build, to building it, to testing it, to maintaining it. Others may just want to do a specific piece of the overall puzzle.

Answer 3

Is there anything more to take besides this being a junior position and they don't have enough invested in it to consider it particularly important to write a useful job description?

I would read it more as indicating that the people you will be working with have not been part of the process so far. Hopefully the company is in the process of hiring a whole new team (and possibly their first ever team) so your co-workers and leaders don't exist yet. Or they could simply be doing very generic work (viz, using a standard set of technologies across the company, and your team works for whoever has a need next). Another optimistic possibility is that they're filling a number of vacancies across broadly similar roles and will pick a position for you once they see your CV (I have done this once, but it resulted in an even larger number of low-quality applications than usual).

A likely possibility is that they expect a deluge of applications for any junior position so they process is to grab the first 10 or so plausible-looking CVs from the stack, a couple of people discuss them and pick three to interview. It's close to "we don't hire unlucky people", but it's a reasonable way to select a junior since you're not going to learn much from the CV or interview anyway. What you want is someone who's not awful and has promise, then you see how they perform.

The negative options are many, so I'm not going to list them.

Unless the interview is going to be very difficult to get to, I don't see any harm in applying for the job. Go along to the interview with a list of questions written down and see if you can get answers.

Answer 4

Most job descriptions are not useful beyond the point of giving you a list of what technologies you'll be using and that they want you to be able to communicate.

During your interviews you have to find out what they're building, how they manage these projects and the role of the position you're applying. Whether you like Scrum or not (as an example) you don't want to hear "we kind of use Scrum" or "we'd like to do more unit testing, but just don't have the time" or some other statements indicating they don't have their act together. Get into whether or not their projects are on time. How much mentoring you'll get as a junior developer or is everyone too busy putting out fires to offer any help. In the most hectic shops, some people won't even be able to complete your interview without interruption (Yes, I've had people do work during my interview "sorry, but we have an emergency" type stuff).

Find out what it is really like to work there. Ideally, you get part of your interview where you can privately meet with someone close to your level. You don't want them sitting next to their manager telling you how great everything is.

Ask you manager how you'll be evaluated and the frequency of feedback. A good supervisor can be your savior even when working on an awful project for a terrible company.