23

Management is strictly not hiring a candidate to establish a process or fix our existing process.

I recognize that no workplace is perfect, but I feel that this might be a gray area between something unacceptable and workable.

I'm talking about software and web development, as many of you are in.

I am not the one who decided to hire someone but I was asked to be there to also interview the candidates.

As one of the interviewers, I feel very uncomfortable just with the thought of possibly throwing someone in a development environment that does not implement practices like version control, lacks communication (especially of expectations), and working under the supervision of highly visionary and creative management (thus, lots of changes of mind, constantly thrown new ideas to implement, etc.). I am 100% positive that the candidate will ask us about process and procedures.

What do I tell them then? I can't even answer the basic question "How will you integrate me into your existing system?" or "What do you use for source control", or "Tell me how an idea manifests into a release."? I believe my honest answers to those questions will turn off candidates.

I think management is looking for someone who is willing to work without proper tools and can sense and feel both management and users' ever-changing desires, and implement in due time, and such a hire will also not try to change how things are done.

How I'm thriving myself in this kind of environment is another issue that is discussed here.

So, should we first "clean house" (adequately enough) before hiring, or change our approach and hire someone who ALSO can establish a process because we need that?


UPDATE

I would truly appreciate WHY this question is downvoted. I honestly think it's a worthy issue. I am trying to learn how things are. If you're gonna downvote my question, I want an explanation. I don't want "that's how life is - you'll just have to get hit hard, figure it out, so just suck it up," as I've seen many times on other people's fairly legit questions.

6
  • One word, but I think they would most likely try to find another job and it wouldn't take long before they hand us their 2-weeks notice. Then again, how do we find that Yoda? Jan 7, 2016 at 21:58
  • 1
    I've retitled your question to bring it closer to what you're asking. I imagine some of the downvotes were because your original title gave the appearance that you wanted to hide this from candidates instead of figuring out how to hire people who can thrive in a chaotic environment.
    – Lilienthal
    Jan 8, 2016 at 9:57
  • What is the job description that the candidates are hired for? You say you are not hiring a candidate to establish a process or fix our existing process, but knowing where they are supposed to fit in can help.
    – user8036
    Jan 8, 2016 at 13:21
  • 1
    @Lillienthal - Thank you for that wording. When I see that in an ad for a developer position, I will take it as a big red flag. Jan 8, 2016 at 14:04
  • @ThreeValueLogic - What did they ask you, what was your "reality" (which you wouldn't dare tell them) answer, and how did you present ithat "reality" answer (what is your wording)? Jan 8, 2016 at 14:05

4 Answers 4

9

Hiring When I Know Our Process Is Lacking or Deficient

You should be honest to management and the candidates. Your company isn't perfect. No company is. Although it sounds excessively disorganized and also like you have a lot of anxiety and stress over the situation. However, it is a job and some people thrive in chaotic environments.

By honest I do not mean that you should lament or overly criticize your management or the status of your processes. Tell the candidate that if they are hired, your first challenge will be how to integrate the workflow, since you don't have workflow really at all. You don't have priorities that are consistent, so setting priorities will be a "work-in-progress" also. There should be expectations that things will change rapidly and without notice. And there is not real software lifecycle development process - so you can pick what you like!

Any developer that wants a job like that may be crazy, but then they are doing it with the intent of helping you and with full disclosure. Definitely don't lie or undersell the situation. Any developer looking for structure, etc. will get frustrated and upset in that environment.

And there is no reason in waiting to "clean up." When I clean house, I like to have help! Tell your candidate that's what's needed right now. If they aren't onboard, then the job is not for them. And if it's a turnoff to candidates, it will help management realize that you have a hiring challenge that needs to be addressed. But you can only convince them of that by being honest to both them and the candidates.

If you are trying to control the hiring process, it sounds like you've already lost that battle. The company you work for is immature and it is going through growing pains. It would probably be best for you to get help with the cleaning up, process definitions, etc. Doing it on your own adds a lot of risk.

I've worked in a few places like that and it can be stimulating and fun. While at other times, it is horrible and annoying. You may be surprised at who you find while going through this.

18

You write: "you should not hire anyone in your company until you have established a process.", but just as validly "Don't wait until you have a perfect process before hiring people, or you never will".

Don't assume that hiring someone where there isn't an established process is the moral equivalent to throwing them to the wolves. Some people positively like the idea of coming to a place where the process isn't defined. They either relish the idea of helping define it, or they don't care what the process is, or they are out-and-out coding cowboys who love the idea of not being restricted in what they do. If you haven't chosen a source code control system yet then they will get to have an influence on the choice.

Your only job is to answer questions honestly. Your answers will, as you guess, turn off some people. This is a good thing as it reduces the risk your new-hire leaves right away after seeing what was behind the window dressing.They might turn on others. Perhaps a candidate comes by that excels at selling a vision to management and gains support to define your current processes. By being honest you are going to get the kind of people you want - ones willing to work in an ill-defined work environment and be part of shaping it.

6
  • I wish we were hiring for that purpose (establishing the process) as well. That, I believe would solve everything. Unfortunately, management is quite reluctant to adapt modern practices, so I am hoping to find someone who will manage to (dare I say) perform magic. Jan 7, 2016 at 20:37
  • So, do you have any suggestions on how we should write the ad for this position? Jan 7, 2016 at 20:40
  • 2
    "You like when everything is on fire, and you've got to put out the fire with a tea spoon of water? Then you'll love working with us". I liked to do that, for some years ago. I remember answering "I like the smell of gunpowed" in an interview. I'm getting old, though. More seriously : "a light-weight, low-constraint, quickly reactive environment" is equally true, and more acceptable to management.
    – gazzz0x2z
    Jan 8, 2016 at 11:33
  • 4
    @gazzz0x2z I'm getting old too, and if I hear "quickly reactive environment" I usually take that to mean "we don't usually think things all the way through & look at the long term/big picture."
    – alroc
    Jan 8, 2016 at 12:13
  • @gazz0x2z - That is exactly how I feel. We've got a fire. I've got a teaspoon of water, and (facetiously) we're getting help for putting out the fire with another teaspoon of water. Jan 8, 2016 at 14:09
4

No workplace is perfect. If you wait until your company has no conceivable problems before hiring, you will never hire anyone.

Maybe your company is more messed up than most, maybe not. So what? Honestly tell applicants the reality of the job. If they are willing to take the job under those conditions, that's their decision.

Any time I've applied for a job, I've taken it for granted that there are pros and cons. Sometimes I learn things about a job that make me decide that I don't want it.

For example, I once applied for a job where through the interviews it became clear to me that I would be doing maintenance on an out-dated system, that my job would be to keep a technological backwater afloat indefinitely. I was concerned that that would be boring and frustrating and, as I would have little opportunity to learn new technologies, I might find myself stuck in this technological backwater.

On the other hand, I once applied for a job where it turned out that there was a virtual war going on between two departments, and if I was hired, I would be dropped into the middle of a contentious situation. But the job looked interesting in a lot of ways, so I was prepared to take it. (As it turned out, they dithered and another place where I interviewed offered me a job first, which I took, so I will never know how that would have turned out.)

Personally I might be very interested in taking a job at a company that is disorganized and knows it, with the thought that I could be part of the solution. I might accept a job that seemed horrible in many ways just because it paid really well or had great benefits. Even if the job you have to offer is absolutely terrible, if the person's other alternative is unemployment and living in a cardboard box, he might decide this is the better option. Etc.

Presumably people who apply for jobs as software developers are adults. It's not your responsibility to decide for them what makes a good job and what makes a bad job. As long as you don't lie to them or try to trick them, let them decide if it they want the job.

2

Be honest, but that doesn't mean you have to describe everything based on your perception. Try to think about the job from the perspective of someone who may like this environment. The candidates can then figure-out if they fit or not. I don't like IPA beers, but if I wanted someone to try it, I would say, "If you like a hoppy beer, try this one."

If you tell me your company doesn't require source control and requirements change often and are not communicated effectively, then I'm definitely using source control. It will make this job easier to get things done faster. That's what someone with any level of experience will do.

Although it does seem like your workplace is more chaotic than most, it does offer a programmer some freedom to put her own best practices in place along with some variety of work in a fast-paced environment. It's not for everyone.

Many programmers over-engineer things. When a company just needs to get some semblance of a website up and running to satisfy potential investors (We just need to have a site like every other company.), programmers start thinking about performance and scalability over the next 5 years. In defense of programmers, they often don't hear the whole story and are just told to build a website and have it ready by the end of the week.

5
  • 2
    How can a chaotic company that changes its mind frequently not use source control????? I can't even imagine how it works. That's going to be a HUGE red flag for all but the most anarchist engineers.
    – Mohair
    Jan 8, 2016 at 16:36
  • @Mohair - THANK YOU. I'm wondering why is it that most of the responders so far think that my issue is failing to empathize with individuals who thrive off chaos. Jan 8, 2016 at 16:53
  • @JeffO - I haven't said it in the question but management at this time is adamant about being able to edit the production website anytime without telling anyone else, thus strongly discourages the use of source control because source control discourages "editing production on the fly". One "reward" I personally gain from my experience is it forces me to be a better communicator and manager in general. Jan 8, 2016 at 16:56
  • 1
    @MickaelCaruso - All the more reason to use source control. If there are suspected changes to the production site, copy the site to another location and treat it as a branch to be merged with the developer's code. Even if you don't merge it, at least run a diff and see what changes were made. Then some sort of presentation could be made to management and say, "This is what has to be done when you make a change." If they accept the consequences (delays and wasted effort) they may see the error of their ways.
    – user8365
    Jan 10, 2016 at 13:08
  • @MickaelCaruso - Those that "thrive" in chaos are probably the team members that also cause it. Also, the idea of sitting in meetings for weeks and months along with going through levels of bureaucracy can be mind numbing. Change is inevitable. Accept it. The problem in your situation is that it is not being managed. Daily changes are very hard to manage, but it can't be done.
    – user8365
    Jan 10, 2016 at 13:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .