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?

  • 1
    @DarthFennec maybe the small modular functions are just for self-documentation. (I once divided a 1,000 line while loop into a bunch of smaller functions -- thank the Deity it was the green bar fanfold paper era, and I could print it out to lay out on a lunchroom desk! -- and none of the new functions were reused by anything else.
    – RonJohn
    Commented Jul 22, 2019 at 19:28
  • 7
    Who are you interviewing for? Yourself, or the company? Commented Jul 22, 2019 at 23:09
  • 9
    We wrote plenty of comments in 1979; a meaningful comment on every line of assembler was considered good practice. Commented Jul 23, 2019 at 0:32
  • 25
    @WesleyLong - I think you and everyone else is misinterpreting the meaning here. The guy isn't saying that the disk space is expensive, he's saying comments are worthless. Something like "this book isn't worth the paper it is written on". It doesn't mean that the paper is expensive, it means the book is shit.
    – Davor
    Commented Jul 23, 2019 at 11:05
  • 12
    If there's no code review process, how does anyone else at your company know whether or not you are following the rest of their bad practices?
    – asgallant
    Commented Jul 24, 2019 at 15:28

10 Answers 10


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.

  • 5
    Great answer. In addition, I'll also try to find examples of 'bad practices' that were being followed and the steps I took to rectify them (e.g. switched to x to reduce build time y factor, revamped the testing automation framework, etc. etc.)
    – Shaishav
    Commented Jul 22, 2019 at 12:20
  • 15
    This could tie into a "overcoming obstacles" question. "Obstacle to learning about this stuff in practice was boss at previous job. So I took steps to learn independently and practice on my personal projects."
    – thosphor
    Commented Jul 22, 2019 at 13:11
  • 9
    I tend to say where I used or learned something, rather than where I didn't. If the interviewer picks up on the current position not being mentioned and asks why, simply stating the company doesn't use it and emphasize your interest to work with a company who does. This isn't talking bad about your employer, it's stating facts. Stating an opinion about how bad not using something is talking bad about the employer, so stick to facts in a non-judgmental way. Commented Jul 22, 2019 at 16:24
  • 5
    This is the answer, but I think it's also important to say that no sensible interviewer rejects a candidate just because they were forced to follow bad practices. If you can articulate why good practices are good, then you are not going to fail an interview for that. Commented Jul 22, 2019 at 16:33
  • 2
    ...and you had some good example code, that you were legally allowed to share.
    – Criggie
    Commented Jul 22, 2019 at 20:47

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.

  • 5
    This. I always described my current work environment as one where we didn't do [those things] and how it was something I wanted to do because I could see the issues that were arising, such as bugs or other changes getting lost in email or unreadable and unmaintainable code or accidentally crashing Production with a typo and how I spent the better part of 2 years trying to introduce better practices. I never blamed anyone with those statements, they were factual occurrences (some of which were my fault!). Commented Jul 22, 2019 at 15:18
  • 8
    Java 1.2/1.3? 20 year old code sounds...about right. I have to maintain code of about this age and older on a semi-regular basis. Sometimes I want to have a likeness of one of these old programs carved in marble and mounted on a plinth, with a discreet brass label that says, "In Memoriae Pre-ANSI C, 1972 - 1989 : Lest We Forget" :-) (Or publish a poem: "In basements cold the poppies grow / Amidst the disk drives, row on row..." - I once worked at a time-sharing company that had huge rooms full of nothing but washing-machine-sized mainframe disks, whirring constantly...) Commented Jul 22, 2019 at 16:58
  • @BobJarvis Yep, that was about it for the age. The thing is, for the whole time I worked there, it ran on OpenJDK 8, so it could be refactored to be java 8 compliant and sometime we did. But the esoteric nature of the code and the specs made it a long job and while management was always going about how we should feel free to refactor, whenever you mentioned you had to do some refactoring they were adamant that it wasn't necessary and there wasn't time to do it before shipping this or that feature. Commented Jul 23, 2019 at 7:49
  • 5
    @FrenchFigaro: management doesn't want to be upset. They get upset when you tell them things. Therefore, management doesn't want to be told. Commented Jul 23, 2019 at 12:51

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?).

  • Couldn't agree more with this. I am always impressed with a someone who knows about the right practices despite being in a discouraging environment. That shows he/she is motivated, curious, passionate. And such folks just flourish in an encouraging environment.
    – Niks
    Commented Jul 23, 2019 at 9:25
  • 5
    I would agree, as an interviewer I find it positive if the candidate tells me he is not satisfied with the way Software craft is done at their current job. You just need to make sure people see your passion for it and it should not come over as picky or illoyal.
    – eckes
    Commented Jul 23, 2019 at 12:06
  • Yep, the answer to any question like this is absolutely: "how can I frame it in a positive way"?
    – aw04
    Commented Jul 24, 2019 at 13:52

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.

  • 2
    +1, I actually think this sums it up best. This way you show that you're aware of the issue, you've tried to fix it, and now you can't you see it as a blocker to working effectively.
    – berry120
    Commented Jul 23, 2019 at 10:58
  • I agree that this is the best approach.
    – user70848
    Commented Jul 25, 2019 at 17:04

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.

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."

  • "My preference is to <good practice>" is a perfectly reasonable way to communicate that you like good practice. Unless you draw attention to it (like emphasizing "preference"), the interviewer will probably just move on to the next question. Commented Jul 23, 2019 at 0:36

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.


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.

  • 2
    You can express interest in using these practices more effectively without getting sidetracked into how bad things actually are in the current organization. Commented Jul 22, 2019 at 15:35

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.


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.

You must log in to answer this question.