I've been a part of this industry at a professional level for more than two decades now, and in that time I've worked for some AMAZING companies ... and a couple of appalling ones as well. All of that experience helped me to realise the FIRST LAW OF PROFESSIONAL SOFTWARE ENGINEERING:
When you're being paid well, respected, and are made to feel secure because of the company's loyalty towards you, you'll rarely think twice before putting in that little extra bit of effort into your work. Conversely, when you're being paid less than you're worth, your supervisor or boss is an absolute PRICK, and you feel sick merely at the thought of having to drag your ass into the office tomorrow ... well ... the company pretty much deserves the shitty performance you can barely manage to put in each day for them.
Since the SECOND LAW OF PROFESSIONAL SOFTWARE ENGINEERING states that the quickest and easiest way to get a bump in salary, is to start a new job - but that extra $10,000 / year is NOT worth it if you end up in bad company! So, it's in your best interests to figure out which kind of company is which WHILE YOU'RE INTERVIEWING for your new role.
Now, when it comes to Job Interview Skills there is ONE that stands apart from all others for me, and if you can master this it will automagically grant you several levels of confidence, and never fails to make YOU a memorable candidate who stands out from the crowd - which, I promise you, is 50% of the game right up front. Best of all, it only takes a slight shift in perspective to achieve truly incredible results - yet so few people ever seem to find their way to it.
I've sat on both sides of that table MANY TIMES OVER during my career, and I can tell you that MOST (as in 80% to 95% of all candidates) seem to fall under one of two categories - either those who FEAR, or those who don't seem to give a damn ... and I've never granted a second interview to either one of them.
The surest way you can be one of the few who stand apart from the crowd, to appear confident, engaged, and demonstrate an ability to maintain a certain amount of control over your situation rather than handing complete control to someone else, is to ACTIVELY PARTICIPATE IN YOUR JOB INTERVIEW and realise that this is YOUR OPPORTUNITY TO INTERVIEW YOUR POTENTIAL EMPLOYER!!
To get you started, here are a few of the questions I've asked potential employers over the past 25+ years in the industry, as well as my TOP TIPS for making sure you stand out from the crowd, and know exactly what kind of people you're potentially getting involved with ... or not ...
Remember: Prior Proper Preparation Prevents Piss Poor Performance!
You don't necessarily want to be reading from palm cards during your interview, but you shouldn't rely solely on your memory to carry the day for you either. A single page of an A4 sized notebook is more than adequate for your purposes, and if you keep it on your lap during the interview, a quick glance is all you'll need to jog your memory. Keeping it casually out of sight this way will, more often than not, lead to your interviewer forgetting it's there at all, making you that much more impressive to them.
If you can't choose from AT LEAST 3 different FANTASTIC answers to the inevitable question of "Why do you want to work for us?", then don't bother getting out of bed let alone crossing town to look like an idiot! You should know EXACTLY what they do, how well they do it from the point-of-view of their market and competitors (ie: their position in the market), who they do it for or to, how long they've been doing it, and if the company is publicly listed, how their stock has been tracking for at least the prior 3 months (or current quarter). DO NOT make the mistake of asking ANY of these kinds of questions during your interview!!
Don't wait for your interviewer to ask "Do you have any questions?" before you open your mouth - but don't overdo it either. Ideally, you should aim to have a conversation with your interviewer. Your manner should be professional, and you should seek to establish and maintain a certain level of mutual respect throughout the interview. Remember - they've likely spent YEARS figuring out the best way of doing what they do, and couldn't care less about your opinion of whether or not they're doing it the RIGHT way. If you MUST query their methods, frame it as a question rather than a suggestion - you may just learn something after all.
You may well be the 100th person your interviewer has spoken to over the past several days / weeks, or even months of their recruitment process, and of course you want to stand apart from the crowd - but it's important to stand apart for the RIGHT reasons. Don't take control of the interview or otherwise prevent your interviewer from learning everything they INTENDED to learn about you, and make sure whatever you're adding on top of that is relevant to THEIR purposes for you. If you throw in any surprises, make sure they are pleasant ones ...
- How would you characterise the learning curve for new technical hires in your company?
- Is the initial training you mentioned for this position formal, or casual in nature?
- What's the most immediate and pressing task you'd need me to deal with if you hired me?
- Who do I report to, and does anyone report to me?
- How would you describe the company culture here?
- Does the executive team actively and deliberately guide company culture, or do they have a more organic approach?
- What would you say is the balance between firefighting (urgent, unplanned tasks) and structured project work?
- Which metrics do you use to determine whether a developer is a productive and valuable member of your company?
- What would you say is the balance between soft (communication, time management, etc) and technical skills in your team?
- How often are you turning over staff, and what measures do you have in place to deal with turnover?
- Have you taken an active approach to the diversity of your team, or have you left it mostly to chance?
- Can you describe the flow model you use here, and are all developers permitted to deploy to production?
- How do you define code ownership within your team, and do you have a strategy in place to create and manage "experts"?
- Do you do formal performance reviews - how often?
- Do you have a dedicated SCRUM Master, or does the team share the responsibility of time and project management?
- Do you allocate resources for professional development - how much is each developer expected to spend annually on training?
- Can you describe the selection of courses available for developers to choose from?
- Are developers able to work towards formal qualifications / degrees under your training plan?
- Do developers have an amount of time they can dedicate solely to training?
- Do you send developers to trade shows / workshops / seminars?
- Can developers apply to attend trade shows / workshops / seminars they are particularly interested in?
- Can you describe your technology stack?
- Where do you source your infrastructure?
- Was there a particular reason you chose to employ [X-technology] rather than [Y-technology]?
- What is your understanding of your current technology debt?
- Are developers free to choose their own tools [OS / Computer / IDE] or have you standardised your toolset?
- So, why are you hiring right now?
- How much has the company grown over the past 5 years?
- Do you focus on a particular target demographic?
- How are you collecting feedback from your users?
- What would you say is the biggest challenge the company is facing right now?
- Do your developers have access to domain experts if they need to understand more about some aspect of your business?
- How many developers do you have currently?
- Do you run multiple development teams or a single team?
- What level of autonomy does each team have?
- How do product owners and stakeholders communicate requirements to the dev team?
- How does the team share knowledge internally? Is this a managed or organic process?
- Can you describe your SCRUM process?
- Which tools do you use to manage the work?
- Do you employ pair programming? Is it commonplace within the company?
- Do you employ peer code reviews? Is it commonplace within the company?
- Do you write unit tests, functional tests, or integration tests?
- Do you have staff dedicated solely to testing and quality control?
- Is your codebase well documented? Which tools do you use for document management?
- Do you have a formal documentation standard, or is this left up to each developer?
- Do you have a process of review for documentaton?
- Do you have a CI pipeline?
- Do you use Continuous Deployment (CD)?
- How often do you deploy to production?
- Is there a time when developers are prohibited from deploying to production?
- Who is responsible for producing requirements, and how are these communicated to the dev team?
- Do you have kickup meetings with product owners, domain experts, managers, and developers when adding new functionality?
- Is it possible for developers to change requirements if they deem it necessary?
- Are you aware of your application's MTTR (Mean Time To Restore) - the average time you need to fix bugs in production?
- Do you have dedicated QA staff? How do QA staff communicate with the dev team?
- Does the QA team test manually, or do they use automated tests?
- Does the QA team use a particular platform for managing tests
- Do you have regular agile ceremonies - like daily stand-ups?
- Do you allow developers to work remotely?
- Do you require developers to spend a certain amount of time in the office?
- Which tools do you use to communicate internally?
- Are developers isolated, or is everyone in one, huge, bullpen?
- Can I visit the development offices to experience the atmosphere?
- How much flexibility do staff have in managing their working hours?
- Do you offer time in lieu when developers need to work overtime?
- Who sets the deadlines for the dev team? How?
- Are estimations regarded as hard deadlines?
- Is it possible to change the scope of tasks if it becomes clear that a deadline is too short?
- Do you think a certain amount of pressure is "healthy" for your developers?
- Do you think a certain amount of pressure is required for your developers to deliver their best work?
- Do you consider any part of your codebase to be a legacy system? Why?
- Do you have a formal process for limiting technical debt?
- Does the management team appreciate the cost of complexity in the codebase?
- How do you limit / control entropy in your codebase?
- How many days of paid vacation does the position offer?
- Is it possible to take an unpaid sabbatical? For how long?
- Can I do a paid trial day to get to know onw another a little better?
- Would you recommend working here to a friend?
- What would you change about the company?
- What is the most interesting project you've worked on here?
- Are deployments stressful? Why?
- How long have you been with the company? Why have you stayed that long?
- Is there anyone in particular you try to avoid while at work?
- How technically savvy are the management team?