My tip on what a candidate should ask in a job interview is what revision
control system they use and how. I had been working once for a big hi-tech
company, and their way to work with a revision control system made the company
an organization not for a talented employee. Working with such a system without
branches sucks a big time. I really hate trying to work on a file and finding
it locked or being asked to unlock a file.
Another thing that drives me crazy is mainaining more than one version: an
advanced one in the developer site, and one in the customer's site.
Comunicating with an employee on-site in order to push changes to an earlier
version sucks a big time. One question they love to ask is "how do you know
this will fix the problem?". I cannot know because I do not test in earlier
version. I once had had to deliver two fixes for two bugs. So, I e-mailed them
tothe coordinator. Worote that fix #1 is for bug #1 and fix #2 is for bug #2.
Got 1 response: "fix #1 does not fix bug #2.". So, I wrote that fix #1 is
supposed to solve bug #1. Got another response "fix #2 does not solve bug #1".
This coordinator had been by that time an expat in the customer site for about
9 years, and with a great reputation. I'd got tired of him, decided he's just
overrated and wrote to him:
Fix #1 is for bug #1.
Fix #2 is for bug #2.
Just know that my work is done.
It was the last time I've ever heard about those two bugs. I do not care
anymore. I think that the best way to deal with such situations is to function
as if you don't mind getting fired.
I could have been by far more productive if they had allowed me to open a branch
and push my solution.