My current job follows "worst practices". How can I talk about my experience in an interview without giving off red flags?

Question

At my job, there's absolutely no code review, no testing, no version control, no organization of software architecture, no concept of "test vs production servers", no code commenting. In fact, all of this is explicitly banned and I often get "in trouble" for writing comments or using small modular functions - my PM says it's not worth the disk space.

Whenever I'm interviewing somewhere else, I'm usually asked about how I work and how I go about testing or verification/validation. I feel like if I was the interviewer and a candidate brought up that there's none of this happening, it'd be a big red flag and I'd just throw away their application. How should I go about discussing this in interviews?

Answer 1

In terms of how to prep for interviews, the best thing to do is to research these topics yourself, and work on personal projects that use them.

For example, my first software job was similar, we didn't engage in any good practices and they were hard to implement. So I worked on private projects, where I could do what I want and had the time. In those projects I would properly plan things, I would set up the src control properly, I would test all my code, I would comment code and try to make it understandable, reusable and scalable, etc.. So when it came time to talk about these best practices in interviews, I had some decent knowledge and experience in them, even if I hadn't been exposed to them at my actual job.

I tend to find that interviewers don't want specific examples of these practices from your current job, they just want to know that you're aware of them and what they involve. You may be hindered from being exposed to them in your job, but nothing stops you researching and using them outside those hours. It'll definitely be worth the time, career wise. And personal projects which exhibit these best practices are great for your portfolio, even if they're small ones.

If they absolutely press super hard for current job examples, then I personally would just say that your current work doesn't really do it, so you took the effort to learn/practice them yourself. That shows initiative and may provide them with extra context as to why you're looking elsewhere.

Answer 2

I've been in this situation recently. At my previous gig, we worked on a very old code base (some java 1.2/1.3 compliant code); code was full of magic numbers and magic strings used to access Object references from Vector's which were then cast; no unit tests, barely any integration testing, none of it automated; little to no time allocated to refactoring old code; no code review; comments esoteric in nature...

When I felt it was time for me to go on to greener pastures, I was asked this very question, I went on about how I wanted to work, and how this lack of satisfaction in my personal work ethics was part of the reason I was looking elsewhere.

I explained what characteristics mattered to me on code quality (robustness from thorough automated testing, legibility from variable and function naming, dividing code into as small as possible functions instead of 1000's of lines long blocks of repeating code, etc) and I landed my current gig.

As @Sascha pointed out in their answer, there is no need to blame your current/previous employer. It's about conflicting perceptions of best practices that prevent you from finding satisfaction in the job you do.

Answer 3

You're framing and approaching this in the wrong way.

The fact that you've got actual experience with bad practices and the harm they do is a good thing. You've seen it, learned from it, and know better than to skip over all these practices that are "slowing you down" and "stopping you from getting stuff done".

What's more, in your own time you've reached out and read everything you can about these practices, implemented them on side projects, and can talk until people get bored listening all about the benefits they do bring to any project and would bring to your specific, current workplace's project -- right?

Present being exposed to the bad practices (important - not following them - as it's not your choice) as experience, and your knowledge of the better practices and their value as something you've learned from that experience.

Not only will this not present any red flags to an interviewer, it will probably come across better than someone else who had only experience of good practices but just took them for granted and may not have anything particularly interesting to say about them (What, that? Yeah sure, that's just what everyone does right?).

Answer 4

I have been in this situation and framed it as me having suggested many better practices but not having been allowed to implement them, which is part of the reason why I want to move on.

That demonstrates both an awareness of the issue and the fix for it, and a desire to work to a higher standard.

Answer 5

Make it a "why do I believe that the company i am interviewing with is great and better than my current workplace" answer.

Whenever I'm interviewing somewhere else, I'm usually asked about how I work and how I go about testing or verification/validation.

Instead of "how I go" answer "how I intend to go". State that obviously producing reasonable quality software is an investment in time and training which sometimes is not considered reasonable due to company background and project types, but that you prefer to work in an environment and on projects where the the things associated with professional SW are executed. If thats true, tell that this is the reputation of the company you are interviewing with.

I feel like if I was the interviewer and a candidate brought up that there's none of this happening, it'd be a big red flag and I'd just throw away their application. How should I go about discussing this in interviews?

• Without blaming your previous employer or colleagues there for something which has gone wrong
• Present the expectation that the company where you apply to does SW development professionally.
• When directly asked, be straight and say that the PM found it reasonable not to implement such measures, and that you executed the jobs assigned as the PM asked. If you did, you can also say that you informed the PM.

Answer 6

Don't bring up your current work environment. It has nothing to do with you working at the place you are interviewing at.

When an interviewer is asking those questions, they are asking for your thought process, that you understand the concepts and you have practiced it before. I would say "Normally, I like to do X,Y, and Z" and NOT mention that your current work environment doesn't do these things.

If the interviewer REALLY pushes for how your work does things, I'd say "Well I like to do it this way, but my current work environment doesn't use best practices, and that's one of the main reasons I am looking for new work."

Answer 7

I'm usually asked about how I work and how I go about testing or verification/validation

Describing your current work practices will indeed raise a red flag. The thing is, you really do lack the skills most companies are looking for. Reading about TDD/Git/Whatever and building a toy project in your spare time using it is one thing. Using TDD/Git/Whatever in your job for the last X years is another.

Realistically, you should try to get a new job at a company with sane working practices that would like to have you on board, get a couple of years of experience there, then apply at a company you would like to work at.

You can try to develop some skills on your own by doing OSS projects in your spare time, but keep in mind that those have to be really good. Many developers use good coding practices at work and have something on Github nowadays, and you will have to compete against those people when you apply.

Answer 8

Try to express before such a question comes up that you would like to move from a risky situation to a company that has more effective practices.

Answer 9

If you want to practice the principles that you believe are superior so that you get experience with them, then I strongly recommend finding an Open Source project that interests you, and contributing. Not only will you get to exercise better engineering practices and witness their superiority first-hand, but you will also have something to point to on your interview circuit.

Of course, private side projects work fine also, but lack the benefit of being on a team of other engineers who give feedback and different perspectives.

Answer 10

Honest answer from a guy who has spent 20 years designing and implementing VLS industrial software systems with 100s of thousands to millions of lines of code and 1000s of square feet of UML diagrams and 10s of thousands of pages of documentation, including test cases following strict FDA guidelines for pharmaceutical industry for creating UHA (Ultra-High-Availability) 9-by-9 (expected reliable up time of 99.9999999%) software system?

Unless you are applying for a software project management position - none of that matters. Just show me you are a good software engineer who can write good working code and intelligent enough to quickly learn OUR "best practices" - and you are good to go.

True talent for designing and writing software is something truly unique - bureaucracy and corporate structure (including communication and documentation standards) is different from one company to another and not that hard to learn. Especially that you are not being hired to implement or lead that structure, just to follow it.

Post Scriptum

Comments in the modern code ARE a waste of time. You should write self-commenting code like

public CapsuleOrder GetOrderByPoNumber(String PoNumber) {}

Everything else should be in the ACTUAL documentation system.