How to find out if a company follows best practices in development? [duplicate]

Question

I've been on Stack Overflow and Code Review for some time and I admire people who help there and provide amazing code reviews. I myself have also quite a bit of experience. Unfortunately to meet and work with such people in real life is almost impossible.

Each and every company I worked for (approx 8-12 so far, also as a contractor) was so unprofessional that I wonder how it even still functions. People there had no idea about the most basic concepts. Everywhere magic strings, namespaces named Classes, classes with several responsibilities, everything you can do wrong they managed to do it this way.

What is worse, they did not strive to improve. They needed tremendous amount of time to implement simplest changes because their code was so bad.

I decided to try to find a new job where I can work with real professionals so I created this new account to ask this question (because I use the other one for CVs).

The question is: How do you find out whether a company employees are good at what they do?

Would you say it's a good idea to ask for a sample of their code? If they want to check what I can I would also like to see if they are worth my time. I don't want to waste almost my entire time at work debugging some old code where each variable is a tmp1, str1, lst3 to tmp23.

I don't want to be just a coder but an engineer and create software that is robust and extendable because of its design and not because of try/catch everywhere and hundreds of ifs to fix some stupid bugs or few hundreds lines of code inside an event handler.

I've tried linkedin and xing but closed both accounts after I noticed that most people have just fake confirmations about their skills.

What should I do to not only be interviewed but also to interview the prospective company. Do you have any experience with that and could give me some advice?

Should I ask for a trial work?

Should I bring my own questions to the interview?

Answer 1

It's not a question of bringing the subject up in the interview or ask trial work, it's way before that: you need to do your homework before applying for a certain position/company and understand if it offers what you are looking for.

You have stated you are a contractor. It's likely you were hired to fix problems and or create solutions for non-IT companies (companies which the core business is something non IT related).

It's clear to me that if you apply for, say, a retail company - you will find an internal IT department at best with limited knowledge about your skills. They will maintain some staff to do the basic maintenance of the systems they have and for bigger projects they will probably outsource it.

In your shoes I would apply for either an IT Consultancy company (Consultancy companies will demand more from you, but you will work with usually very skilled professionals and pushed to the limits) or a sofware houses with a relatively big presence in the market. Not to mention Big techs like Google or Microsoft where I've never worked for but will guess their staff must be close to the best available.

Good Luck

Answer 2

Firstly good luck getting them to give production code to a candidate.

I have one suggestion that you may or may not like. Maybe you should try applying for a start up. If the company doesn't have existing products and you're part of a very small team you can shape the coding practices and hopefully grow with the company i.e. have input on their hiring decisions.

As @User012876768 suggests, the alternative is applying for the Marquee IT companies as they will often have their pick of grads. I've never worked for a company like that but you would imagine they have fairly tight coding standards.

Answer 3

Here's the thing: interviews go both ways. So make sure to ask them questions to let them convince you of their competence. For example, ask them what tools they use, what code standards they have, what their process is, how do they ensure code quality, what they think about their code base, even what they think their company can work on, what do they do to try to identify and fix problems, and what their company is good at. When you do technical interviews, use it as an opportunity to start a two way dialog, and also think about does your interviewer seem like they know what they're talking about too.

Use this technique, and it'll work for you in that it makes you look like a good candidate, AND you will get an idea of the company's quality too.

Answer 4

With virtually all companies, you're not going to be able to see private code before being hired. What you can try to do is to find people who previously worked there and see if they're willing to comment on the state of affairs.

If you want to see significant amounts a companies code before being hired, you're going to need to be selective in what types of companies you apply for. For most fields of software development you'll be limited to companies doing major amounts of open source work are the easiest ones to do so: Find out what projects they work on, look at what their people are committing to public repositories, and see what they're advocating on discussion lists/etc. The only major partial exception is companies who do public facing web development; in those cases you can look at the client side half of their sites look like although the backend will largely remain a black box.

Answer 5

What should I do to not only be interviewed but also to interview the prospective company. Do you have any experience with that and could give me some advice?

The best way to learn about how the company/department actually works is to talk with someone who actually works there.

If you have someone in your network with inside knowledge of the company and its development practices, talk with them.

If not, during your interviews try to talk with someone who would be one of your peers in the company. When I'm the hiring manager, I make sure to include a peer as part of the interview process. When I'm the candidate, I ask to speak with one of the peers of the open position.

During this discussion, you can ask about the company, the manager, and all of the processes in use.

Don't just ask "Do you follow best practices?" because "best" is very contextual. Instead, ask about the specifics that are of interest to you.

Should I ask for a trial work?

You could. Some companies make a habit of hiring people for an initial trial period, and would welcome that offer.

Should I bring my own questions to the interview?

Always bring your own questions.

Not only will that ensure that you get the answers to items you need to know, but it will demonstrate your interest in the company, the job, and your career. Those are all good signs for hiring managers.

Answer 6

Ask for opinions from your tech-oriented peers, teachers and mentors about the reputation of any company you're considering, along with suggestions of other places you should consider.

I emphasize "tech-oriented" because a great culture for a firm's salespeople or customers might not translate into the same for their engineers.

An ideal source of insight would be a hackathon, where you can work directly with tech and other people from within the company.

Another source of insight is customer ratings / service complaints - if the products stink and the service is terrible, it's unlikely it will be a great place to work, especially if they are a technology company.

In this vein, if possible, become a user of the company's products and services. This will provide terrific insight.

Lastly, yes, do have questions for your interviewer(s), but make sure they aren't simple ones that are already answered on their website or elsewhere. Asking "How many employees do you have" makes you look lazy and unprepared. Good luck!

Answer 7

Companies can be big places. One group or division may have completely different practices than another.

I would not worry too much about what other people in the company are doing. Usually each programmer works on their own stuff. In 25 years of programming I have never had somebody mess with my code at any significant level. When people take over other peoples code I find they always rewrite it completely.

As far as debugging other people's code, that is inevitable. The more junior and less productive you are, the more cleanup and junk work you will get. If you are highly productive, you will spend very little time doing secondhand coding. There is nothing more annoying than a junior 3000-lines-a-year programmer complaining about the style of the base code. Once, a company I was at hired a contractor of weak abilities who was assigned to work on some components which were a tiny fraction of my output and complained about my "spaghetti" code. Of course, Mr. Beautiful Code did not actually write much beautiful code and consequently he was fired after a few weeks.

Personally, I never have a problem with other people's code. I don't care how bad it is, or what language it is, or what its style is. I am a master programmer so I can handle it and it doesn't bother me at all.

Once I wanted to play tennis with somebody and they refused, saying, "Sorry, I don't play with bad tennis players because it throws off my game." That's the mark of a total amateur. If you think playing with a novice will "throw off your game", you have a long way to go to master class.

If you want to know what good code looks like, check out Google Code Jam. The submissions from the top guys there completely blow me away. I am a very good programmer, but seeing that stuff, it is like watching a grandmaster play chess, just amazing. Forget the OO nonsense your professors spout, they are worthless; let the Code Jam guys be your models, because they are gods. You will learn WAY more reading their code than some dumb design handbook.

Answer 8

Nobody 100% agrees on best practices, especially since the recommendations keep changing.

Nobody 100% implements best practices, for reasons ranging from past history of the project to needs of the business to up-front cost of adopting them.

And it 100% doesn't matter. If you're any good at your craft, you can adapt to the environment they do have, learn what the constraints are, and then work with them to introduce improvements where they make sense.

A good workman can do good work even if the tools aren't the latest and greatest. And that includes cognitive and process tools as well as the ones more commonly recognized as tools.

That isn't intended to defend the old tools... just to defend their users, and to suggest that setting this particular requirement may cause you to reject some darned good opportunities.