Rules for job seekers to evaluate software companies?
Awhile ago on here there was a post about a list of questions one should ask themselves to evaluate how good a software company is. One was making sure there was a dedicated test team because it's a waste of money to have developers test their own code. I have combed the internet forever trying to find this list but I'm turning up empty. If anybody could help a guy out I'd greatly appreciate it!
20 comments
[ 2.7 ms ] story [ 53.1 ms ] threadSearching for newer versions of that may be useful.
1. Check out their toilet if it's on-site.
2. How does the team do requirement analysis? Do they have a dedicated business analyst team or you guys have to do it, or no one is doing it and everyone is fighting for his own tickets?
3. Does the company HR/Admin send light-heart newsletters every once for a while?
4. How tight is discipline monitored?
This! It’s a distillation of the whole group you’re dealing with from top to bottom (pun intended.)
There was a company, that to save money, had cut the hot water in the restrooms.
Another company visited to discuss having said company provide provide their IT as a service. This was long before the AWS et el. Both companies were Fortune 100 at the time.
The visitors, made the mistake of going to a restroom that was not in the executive suits area. They inquired about the lack of hot water.
The deal, which was hours from complete, fell apart.
If that company treated their employees so poorly, how can we expect them to treat us....
Yes visit the toilet to see if they care or just provide lip service.
- all docs still refer to AWS, so worthless
- server logging disabled
- untrained admins
- few SSD options compared to AWS
- live migrations causing outages
- broken terraform scripts.
Give them a year to sort out their new cloud.
interesting.
Testers also tend to be a little cheaper. To call it a waste might be a bit reductionist but it certainly hints at some organizational inefficiencies that may be recognizable once you reach a certain size.
If you are planning on keeping the code base around for a while and you are going to make changes to the codebase, then you are going to want this. Otherwise those expensive developers are going to take longer to implement the new features and they will introduce more defects into production.
Testers are nice to have, but your developers need to be doing this.
Even if they can it’s a hat switching thing. Building something from 9-10 and then trying to break the shit out of it from 10–11 requires some mental discipline.
For quality I’d rather have testers. Developers will test their own work anyway if they know shit work will be sent back.
Frankly, I think thorough testing makes my code better too. If you can't figure out how to test a function you just wrote, how are you going to get any real reuse out of it later? I don't do TDD, but often testing will lead me to refactor things to be clearer.