Let's face it.
- time consuming
The worst part is that the Company you're interviewing with is selling themselves to you.
Sure it's flattering.
However, there's no barometer of honesty that you can use to judge whether the Company is a good fit or not.
The basic jist of all of this is to show you that you should be interviewing the Company as well.
Ask them questions.
- Do you see yourself here for the next 5 years? (this can tell you whether the Company has passionate employees or people who clock in)
- How would you describe your management style? (if you don't hear a confident clear answer then the manager is a bad manager)
- What are some things people on your team have done that you liked?
- What are some things people on your team have done that you did not like? What did you do about that? (Use this question to trick the interviewers into telling you the Company's problems)
Use these questions/topics as a way to decipher whether a Company sucks or is a good fit for you.
1. Does this Company use version control?
Is there a version control work flow?
Does each feature get its own branch?
Is there a master branch and a qa branch?
Are there pull requests to ensure that code is optimal before branches get merged?
During pull requests does code get reviewed by another developer?
Does each developer have a local environment that's identical to the live environment? Are there tests that could be run to ensure that critical parts of code will work?
If you're not comfortable with the answers given, then say so.
And use this to your advantage when negotiating.
"I'd love to join your Company, but as it is - management can use help with the Git Workflow. I'll be happy to do that, but I want 20% more than what you offered."
2. Are there migrations that are carefully timestamped, managed and versioned to account for database changes?
Is there an overall schema file that you can use to load the most current version of the database?
If not, then your local environment will constantly break because of database issues.
3. What's the process for testing?
If it's manual and there are no tests written then you'll get frustrated working at this Company. Unless you're building a prototype.
If there are real QA people, then make sure they're not idiots by meeting them. If a QA person doesn't do their job then your job will suck.
4. How does this Company handle deployment of the code?
Does the Company have a strict process that ensures bugs on key features will be minimal?
If the answer is no then this Company is used to doing things the wrong way.
Joining a Company like this would be bad for your career, and will also make your job a headache.
Example: Your code could break because of someone else's code that was written after you pushed your code, but it'll be your fault
5. Is the codebase/db a nightmare?
Any of these are a bad sign for the code base/db.
- redundant code
- a lack of comments
- inline styling
- unused tables
- a lack of consistent naming conventions
How do you find out if the above is true?
- ask directly
- ask how often do developers grep the codebase or database for particular things (not file names)? More than once a week is a warning sign.
- Ask to see the codebase. Have a developer walk you through a feature and the code that makes it happen. If they don't want to show you the code then be wary. If you're feeling weird about asking, then say it like this: "Hey ___[coder's name]____, since I showed you my code samples, would it be ok if you walked me through the _______ feature on the site and the code that makes it happen? We could go to your computer now. I just want to see if I can fit in coding here."
A bad codebase/database indicates that this Company
- doesn't care enough to write good code
- doesn't care about the web development team
Bad code could be a result of a few things
- code being outsourced to sub-par contractors
- developers leaving abruptly and then code getting handed off
- poor working conditions for developers (see 1 through 4 above)
- tight dead lines with an under sized development team
- poor Company Management
Joining this Company means that you won't be a coder. You'll be a QA person, and you'll ultimately learn less, and your career will get hurt in the long run.
6. What % of the job will be debugging code and what % will be writing fresh new code?
There are many Companies that are looking to hire Developers that are destined to never write beautiful code. These Developers are brought in to keep a sinking ship afloat.
The ship is a terribly written codebase. Maybe it doesn't have comments, maybe it's not organized and namespaced, maybe the database is redundant and inconsistent.
The one thing that is certain is that nothing will change.
Developers at these Companies will tape up bugs not knowing what else they're breaking and are constantly stressed because everything they do could blow up at any moment.
And guess what?
It's always the Developer's fault.
Companies like this have bad management.
Managers here are ignorant, unskilled in the things they manage and are untrustworthy of the people they manage.
That's why the codebase will never get re-written.
How do you know if a Company is like this? Simply ask
- What new features have you made in the past 6 months?
- Can you describe to me the architecture of those features?
- What classes did you write?
- What do the database tables look like?
- What other parts of the site does it interact with?
- How often has your team completely re-written a feature? Can you describe to me that process? Why did you do it?
0 new features, bad architecture, no organization with lots of interaction with the rest of the site and no code re-writes spell out BAD TECH MANAGEMENT.
Avoid a Company like this.
7. Let's say you hire me right now, what would I be working on? Could you walk me through it? Or white board it?
If they can't answer this FAST in a CLEAR manner
then management at this Company sucks
and you'll end up going on a roller coaster ride of whether your job is safe or not.
8. Is the IT department the same as the Web Development Department?
This means that this Company views the entire Web Development team as a COST
And not as important as the other departments.
This Company will outsource the Web Development team as soon as it can, because it doesn't value it.
If the Company doesn't view the Web Development team as part of the product's success, then joining a Company like this is only a short term plan for you
Because in the long run it will be bad for your career.
9. What kind of equipment do developers use?
Do they have dual monitors?
Are their monitors big enough for viewing multiple windows at the same time?
Do they have better computer set ups than everyone else?
Can developers take their computers home?
If not then that's a major warning sign that developers are not important to this Company.
Instead of asking what the computer set up is like, ask to see where they code at.
By giving developers sub-par equipment, this Company is directly giving the message that writing emails and using Microsoft Office is the same as coding.
This Company doesn't want to invest in its developers to make their lives better.
10. Is your manager a developer?
If your manager isn't a developer then you have a major problem. This means that most of the time you won't be using the right tools for the job.
Not because they're unattainable, but because your manager is inexperienced in coding and won't make sound decisions in what you should or should not be using to get the job done.
This isn't a big deal if it's a trivial decision like Bootstrap versus Foundation, but if it's a decision like what back end or front end framework to use, then a manager without coding experience could make your life terrible.
If you find yourself in this situation, make sure you have the power to make calls before accepting the job.
Example: "I would like to accept the offer as long as I can choose the frameworks and tools that we use".
Of course, if you are in fact the manager, this doesn't matter :).
11. Is this Company passionate about coding?
You can find this out by
- Asking the developers what they're working on in their spare time.
- Ask if they push code often to their personal github accounts? Ask to see their github accounts and their personal projects.
- If the developers don't learn outside the work place then you'll be joining an apathetic and unexciting Company that isn't passionate about web development.
12. Whose on my team? What are their roles? Are they full time? On site?
Is your team full-time in the physical office?
If key people on your team are part-time and/or remote, then you'll have a hard time communicating with them and asking them questions.
13. Am I replacing anyone?
If the answer is yes, then find out who that person was.
Ask how long this person has been here. Where are they going to? Why?
Flags would be if that person has not been at the Company for more than 12 months, and if that person was the sole back-end developer.
Ask to talk to that person.
Ask that person "What was your favorite part of working here? What are a few things that you wish could be different about the work here?"
Those questions should help you figure out if the Company sucks.
14. Is anyone leaving from the company related to my role?
Even if you're replacing someone, there could be others related to your role that may be leaving.
If others are leaving then think twice about working at this Company.
15. Are the other developers easy to work with? Are they smart?
Do they seem like a pain to work with? Are they condescending?
Are they stupid?
Don't be afraid to ask them questions. "Hey out of curiousity what do you think about caching? What are the different ways you've implemented it? What were the results? How does that compare to other caching techniques?"
If the person can't answer it, then you'll be surrounded by people that know less than you.
You eventually become what you surround yourself with.
Tip: if you get tripped up by a question - you can just say "I'm really curious - could you tell me what the optimal way of answering that would have been?"
If the interviewer says I'm not too sure, then you can reply with "I guess I'll fit right in here haha".
Talk to the other developers and ask how they like it at the Company and if they see themselves there for the next 2 years.
If you sense any negativity, then this Company may not be stable. If key people leave this Company, then you'll be stuck with the majority of work.
16. How is work assignment done?
Are people going to walk up to you and ask you to do things?
With no system in place, you'll be spending long hours randomly at the office. Maybe even weekends, because there's no project management work flow.
Do features go from ideas to tasks into an online task management system? How are bugs handled? What about midnight on Saturday?
Ask "What's the latest you've stayed at the office for? How many weekends have you worked?"
17. What are the work hours like?
How flexible are they?
Do you get to work from home here and there?
I once had a position that was 7 days a week and 12+ hours a day (not including a 3 hour commute). You can imagine how I felt when I found out about the work hours.
18. How clean are the bathrooms? (Obviously don't ask this - just check)
Seriously go check them out.
Are they clean? Do they have nice toilet paper? If not, that means this Company sucks.
Don't join a Company that doesn't care enough about its employees that it skimps on something that everyone uses everyday.