How to understand the quality of the code in the company already at the interview?

Question

Programming

I caught myself thinking that at the interview I want to say to the employer: "Show an example of your code" :) Because you often understand what you have gotten into only when you have already settled down and see the project with your own eyes.
How can you find out at the interview what is the quality of the code on the project? At least approximately? So far I’m focusing on indirect signs: the stack, how old the project is, how many developers are in the team, how the deployment process is set up, how with testing ...
You won’t ask: “Tell me honestly, what is your percentage of shit code?” :)

Answer 1

Well, in general, it’s worth starting with what you mean by govonokod. Often, shitty code is not only a crookedly written method/class, it is also a poorly optimized database, a crooked application architecture and incorrectly chosen tools for solving the tasks assigned to the project. In any case, the project is made by people who change on the project, so you need to find out the details of the project development approach in the company itself:
- ask how long the project is in development, the degree of test coverage, if the project is ancient and not covered, then it is bad;
- if the project is old, then find out if the versions of tools / frameworks are updated on it with newer ones, find out what is backwards compatible;
- ask how the process of merging new features is going on, if through merge requests for a team leader, which he approves or rejects, then it’s not bad, and you will be prompted, they will control that it’s not bad. If you push to the development branch, then it's bad;
- if they use merge requests for a team leader, then ask if git-flow is used, if yes, then it’s good, this minimizes the option that you will get a bunch of crashes from what was pushed by colleagues, if not used, then bad;
- find out what is going on with CI on the project, if there are tests, then whether they are launched during deployment, if yes, then it’s good, no, it’s bad;
- if this is a web project that uses backend and frontend frameworks, then you should ask if they are deployed on different servers, if so, then it’s good, if not, then it’s bad;
To find out all this otherwise than by indirect evidence is unlikely.

Answer 2

I want to say - say.
Just keep in mind that then you won’t find any work, everywhere there is shit code

Answer 3

no way. for that and probationary period

Answer 4

Alternatively, interview with companies that deal with open-source products

Answer 5

Just ask. Straight and clear. They will not lie to you (they still work with you), except that they can embellish, but this is not so scary.

Answer 6

Shit code ... mvp is made from a blunder and into production and then endless refactoring. In general, refactoring is endless.

Answer 7

So ask me, when they ask me, I always show

Answer 8

I caught myself thinking that at the interview I want to say to the employer: "Show an example of your code" :) Because you often understand what you have gotten into only when you have already settled down and see the project with your own eyes.

So say - "I like your company, but can I take a look at the project code?"
Usually ready to show.

Answer 9

The more programming questions they ask you in an interview, the more attention they pay to code quality.

Answer 10

You already g_s_e suggested how to do it right.
Ask indirect questions.
I would add to that list.
One programmer is responsible for the project or it can be done by several different programmers.
Is the code reviewed?
Is there documentation.
Is there a standard for writing code.
Is there a need to work after work, on the weekend, for example.
Well, something in this doha. Why is it important? So you will understand, if the company pays attention to this, then for sure they treat the code with respect. They don't do it slipshod.

Answer 11

Answer 12

Even if you ask: let's take a look at your code - you understand that you will get a beautiful section.
You can ask this question. Programmers can be conditionally divided into three categories according to what they like:
* Performer - he is pleased with the result, as quickly as possible and so that it works.
* Geek - he is interested in trying all sorts of trendy things, just a new one came out - he wants to use it.
* Puzzler - he is interested in complex large tasks, where you need to sit, to meditate.
Sobsno question: what kind of person in these categories are you looking for?
Most often there is a mix of two, if they say all three are equally important - the interviewer is deeply purple. If at the same time the interviewer is a technical specialist, this is a very bad sign.
You can also ask who on this scale is on the team. If the team consists of the same type of programmers, this is very bad.
Regarding code quality: ask about the conventions used, criteria for code reviews and test coverage

Answer 13

If the questions are "complex", OOP for example, most likely there is no shitty code.
If they want to find out if you know some banal functions, then the interviewer himself is not very competent, and the employees are even worse and, as a result, shit code.

Answer 14

The question is equivalent to the following "how to understand from a photo in Tinder that a guy is not an asshole, 19 tips from Cosmo."
No way. The signs mentioned here will only indirectly answer the question of the code in the organization being asshole. As many have already noticed here, shitty, excuse me, shitty code, is in any more or less live project, otherwise you get a dreary raid of complete predictability and lack of risks - what kind of business is this, where solutions are not needed "yesterday", where no one checks the concept a quick blunder on dendrofecal technology? Give me two, I want that too! For reference, in the case of men, such a miracle is called manicorn , in nature, as the name implies, is not found.
It will be better if you invent a "scale" or "dating bingo" and thus do an integral scoring of the organization of work in the company. However, this is not a valid test in any case - it can be both a false positive and a false negative result, albeit with a lower probability of an obvious crap.
An adequate option is to find a certain point of balance, at which you are satisfied with your work, and the customer does not throw zucchini caviar in all directions without waiting until you line up all curly brackets for the hundred and first time. And this, alas, is tested by practice, which, alas, is not available without a trial period.

Answer 15

Govnokod and legacy will be everywhere. Because business always needs to be ready yesterday, which pushes first to quickly nagovnokoda, and then (when there is time) to fix it (the main thing is that comments are left in such sections of code) ...