1. The quality of the coffee and toilet paper you encounter during an interview tells you more than promises about table tennis or fruit baskets.

2. Try to determine who their primary client is: subscribers, app buyers, advertisers, etc. It's a major influence on the company dynamic.

3. Before an interview, you can just say: "I would like to sit down with a PO and run through one backlog feature and one bug, to get a feel for the type of tasks at the company". Such an activity immediately reveals team structure, whether they have product owners & scrum masters, what a sprint looks like, how they prioritize tasks, and how organized/chaotic your work experience will be.

Agree on 1 and 2, but 3 may be a problem - you shall not be allowed to see backlog as non-employee. If they let you see it, do not work there. Giving info like this to any outsider willing to see is major security breach imo

Ooh, fruit basketz!

@blem14 Good point. But I wouldn't have to see the whole backlog.

When I interview candidates I do discuss 1-2 specific tasks with them, to check if the type of work is what they expected it to be, and what kind of questions they ask.

I do honestly not see the security issue in refining a task like "build an API endpoint so an account manager can see their sales performance since the start of the month".

@bittersweet Now you know they don't know about their sales performance at the start of the month and possibly could do something with it. You also know that they will know about it soon. I'm not a industrial spy so can't say how exactly this could be used, but maybe something on stock market.

@arraysstartat1

I don't know what kind of military contractor you work for, but it sounds like such an employer would have a very stagnant uninspiring culture.

My current company has several open source github projects (actually, about 65% of the code is in such libraries), and a bunch of projects which are private repos but nevertheless have pretty much fully public Trello roadmaps (I think about ~25%). We do have a fully closed core product with private Asana boards (probably around 10%), but it's a pretty small part of the company.

Worrying THAT much about corporate espionage is only useful when your intellectual property is worth more than your end user loyalty... which, to stay on topic of wk144, is another sign to avoid an employer in my opinion.

Doesn't necessarily have to be an evil employer, but for me it would take all of the fun away.

Public transparency & happy end users are essential for me.

@bittersweet Dunno, maybe in web it's like that but I'd imagine that most software is still proprietary, like in automotive, ...or in logistics and security/AV (the latter two I've worked in)

How can you do #3? That would be after they extend you an offer?

@phorkyas Ah, industry differences. Yeah tbh I've also worked in aerospace where it was a bit tighter controlled, although the software I worked on was a lot of open source as well.

@billgates Not necessarily. As a milder version you could just ask: "could you give me an example of a feature recently finished by a team, and tell me a bit about the team roles and the workflow. And what was the biggest challenge experienced by the team?"

It's not weird for a company to have delays, or still struggle with optimizing code reviews, or have too much meeting overhead.

I'm suspicious when a company says "code review? What is that?". I'm also suspicious when they say: "we do code reviews, and it eliminates all problems".

I interview about 3 devs a week, and when they can't tell me what they want to improve about themselves it's a bit of a red flag.

More so than their dev skills, I want to know about their learning skills and work process. Do they ask fellow devs for pair coding sessions? Do they read books or watch online courses?

As an interviewer I look for honest answers about current knowledge, and the vector along which someone is educating themselves.

As an interviewee, I expect the same from a company. I want to know their process, which parts they struggle with, and how they are trying to grow in those areas. If they claim everything is peachy, I poke harder.

@bittersweet Number 2 is confidential. I think most companies will not tell you that. And may apply to Number 3.

As @blem14 said, in short Non Disclosure Agreement.

The 2nd one is so important. If the clients dictate your agile, they dictate the whole day.

@bittersweet you would not have opportunityty work on open source everywhere, unfortunatelly. In my area there is no company doing open source. All are under strict NDA, and some even lock office rooms with access cards. Of course if you use vague terms, not giving out the customers and projects, it would be really nice for the applicant, but what I was allowed to say as recruiter is not that far from what they may read on our website.

I would be really glad if applicant asked me how we share knowledge, is pair coding a thing or do we do reviews and how, but they seem to not care.

Approach is up to client in our company, we don't make our own things, so that might be why my experience differ from yours. I tried to "spread the word" in our internal projects, but they were just "meh, it should just work, nothing more" 😐

@blem14

If the end user/client directly dictates the development process, you have your answer to the question "how to avoid bad companies" right there.

The product itself doesn't even have to be open source for some transparency about company procedures, that's just some end of the spectrum.

Without the code being open, you can still be fairly transparent about the company.

Sharing details about tech stack, team composition, hierarchy & workflow and maybe the refined details of a roadmap task with a prospective hire, is absolutely not the same as handing over a copy of the code & database.

If a company has NDAs to protect the product, but no POs or a clear agile/scrum workflow to protect developers, I'd run away and torch the place behind me.

I've worked at companies under fairly severe restrictions, yet I still asked questions like "how do you version your code", "who is responsible for code reviews", "who refines the requirements for tasks" and "can you quote me a task the team recently worked on".

At a biochem lab I worked on machines which automatically performed elisa tests on contagious variants of influenza. In aerospace I worked on machine vision software classifying xray dicoms for NDT QA of rocket & bulkhead welds. Both companies (eventually) had dev teams working in 2 week sprints. Both had some form of customized scrum with mixed success rates, both had multiple levels of code reviews.

Do I break my NDAs by telling you about the tasks I performed? Nope — the companies themselves consider all of this public information. Their dev workflow is published in HR recruitment ads.

Would I break my NDAs if I sent you specific implementation details, or any of the proprietary code, or pictures taken in factories? Yes, certainly!

The first step is understanding that the company must be good for you also. Sometimes we think that in the hiring process just we must be approved, but no. They are not doing us a favor. It's a partnership. They are beeing evaluated too.
So, don't be uncomfortable to make questions about the aspects you think it's important. And don't be afraid to cite points you disapprove. The companies even don't know what we want. So, It's your responsability tell them.

@matheusasdev 👌

@bittersweet agree with all, except first sentence.

All projects in my company are driven by the project leader on the customer's end. We are more of a subcontractors for them. That means they have they proceses, their tools etc, and their employees use them along with us. I can't see it being two separate proceses in such case.

If company create their own products, I agree, that would be horrible to not have own proces and let customer decide.

@blem14 What I mean is that in my opinion, it's a bad idea to have clients directly dictate what developers do, on a day-to-day basis. There should be a level of separation.

There should be a central project manager / product owner for a team, someone who plans, prioritizes and refines tasks for developers.

At some companies, that layer is very thin -- any random client shouts "we want a button!", your boss hears that, and shouts at you "the client wants a button!".

I've never worked effectively at a company without a buffer in between, a rational person who is good at negotiating, preparing, writing detailed requirements, and leaving developers the fuck alone when they are still working on the previous task.