Pros
- Allows remote for Autoloop employees, but for how long? (See reviews below) - Has made lots of changes in the last 2 years in including all employees in product direction. - There are some really great people (and some not so great) to work with - Pays roughly adequate for Clearwater average salary (you can do better if you work remotely for a company elsewhere) - 2 week sprints (but see counterpoint in con's)
Cons
There is no question, I am looking for other work before my mental health forces me to quit without a backup plan. - CTO (who was a great CTO) surprise-quit over the Christmas holidays. Employees were shocked to hear the news when they got back. People jumping ship is becoming weekly news. Lots of product expertise lost to the void due to high turnover. They either can't find new hires to replace the people who leave, or they can't hold on to them, but either way, responsibility is spread out among already overburdened employees. - Technology is archaic. We are still using ASP.NET webforms and AngularJS (1.5) creating new controls and development every day. This is a great company to get "stuck" at. Good news though, we no longer support IE 10. - This company is supposed to be Agile, they use Storypoints for estimates... BUT, don't be fooled. They also require a very rigid time estimate in hours. Going over the estimate always prompts big questions and reprimands. They have said repeatedly over the years that the hourly estimates are for "tax purposes" only, but in the last year there has been a much bigger focus on accurate hourly estimates, to the point where they are starting to hold teams and employees accountable to their estimates. Do. Not. Make. a. Mistake. - They are supposed to be Agile, using 2 week sprints. However if the case you are working on cannot be finished by "Code Complete" you are expected to work the weekend to get it done without compensation... because you estimated that you could (see "tax purposes" above). - Supposed to be Agile, but when Code Complete is in place and QA is hard at work testing, devs are expected to find busy work to fill the time (normal I guess). This includes grabbing an "Inquiry" to log research against even if you expect that you cannot finish the inquiry by the end of sprint. The kicker is that if you pull an inquiry into the sprint but do not finish it before the end of sprint even if it is the last day of the sprint, you are not allowed to move the inquiry to the next sprint. Instead you must create a duplicate and drop it in the backlog until some later date. - The above mentioned 'Con' about inquiries maybe is not so bad BUT, here they use inquiries as cheats to do investigations on actual bugs. It is not uncommon that an inquiry looks like "Feature X is broken. Find out why and what the fix is". Then you must find the bug and the solution, but not fix it. Also you are not allowed to have cross sprint branches so you must not create a branch with the fix in it. The solution? Hold on to the fix (mentally or in comments or in a separate document) and then paste it into the solution when it is pulled into the sprint. This leads to the same kind of issues you would see in a Waterfall environment. At the beginning of the sprint, devs grab these copy/paste fixes, add them to the solution and let QA start QA'ing them. When QA gets bottle-necked, do more of these "inquiries".