Interview technique
My interview practice is I guess somewhat non-standard, based on what I see when on the other side of the (virtual) table. For most roles, the practice seems to be:
I don't do that.
When I'm in an interview, I'm 100% honest about my skills, attitudes and beliefs. What you see during the interview is exactly what you will get during the contract. I will question development approaches during the descriptions of the project if I have experience of alternate approaches. Not because I want the project to change to my way of doing things, but because I'm trying to gauge the flexibility of the team, and whether they do consider continuous improvement on the project.
I make clear my attitude to code quality and testing. Those are areas I will not compromise on. I have no problem bringing teams up to speed here as part of my work, but I refuse to work on projects that are doomed to produce buggy, not fit-for-purpose code. That's just soul-destroying.
I will ask difficult questions about team dynamics - do the team members communicate and work well together, helping each other be as productive as possible; or are they a bunch of compartmentalised drones that don't know or care what each other is doing? If the latter, do they want to stay that way?
Recommended by LinkedIn
Being honest here saves a lot of hassle down the line. For example, on a recent interview for a project, it all seemed to be going well until it was my turn to ask questions. Turns out the project had minimal testing, and the attitude was basically that the tests would slow them down, and they'd be added later (yeah, right 😉 ). I stressed the importance I place on testing and the meeting was shut down pretty rapidly at that point. It was a good shout, as my principles would not have meshed well with their team. (I reckon the project is doomed though 😀 )
Many interviewers are fixated exclusively with the technical questions. That's fair enough for junior roles - focussing on tech is important as by definition junior roles don't require the leadership and coaching skills. At senior level though, I reckon the tech skills are only a part of the requirements. At my level, I'm focussing both on getting the dev done, and in improving the overall team productivity and project quality. You don't get that just talking about the tech stack.
In a lot of instances for what I do, details of the tech doesn't matter. I'm expected to either know or learn quickly individual APIs, libraries, tools, etc. That's a given, and I know I'm really good at it. What's more important is the experience to know how to use the components most efficiently, and the ability to explain and pass on that experience to the team.
It's difficult to demonstrate the latter in an interview, particularly when it is geared just to a tech evaluation. From experience though, that is what generates most value for clients.
Interesting. It reminds me relations between companies. Negotiation and business as peer-to-peer relations or partners opposed to top-to-down approach. Companies expect bigger flexibility from people they hire - you do what we want and we take care of cash inflow. Of course such approach suppresses expertise application. As client doesn't want tooth to be drilled. On the other hand partnership assumes that all participants have skin in the game in short and long term outcomes. Nice that you Donal have opportunity to participate in projects as an expert. I have many theoretical questions about this type of work. Haha 😄 almost no answers. Despite few years of my work as a freelancer 😂
Well put. One of the most valuable lessons a contractor should learn is that you don't have to win them all. Even more bluntly as a former associate of mine, now deceased, put it "sometimes you have to recognise that you are dealing with the client from hell!". Once that lesson is established and you've grasped that an interview works both ways, we can each develop our own litmus tests to determine whether we are engaging with a client we really want to work with. Being discriminating can sometimes mean time on the bench, but in my opinion it's better than letting desperation drive you to taking on a role that can frustrate or even destroy you.
I really like that you wrote this Donal, everyone out there needs to know the difference between good companies to work for, and the feeling of emotion that exists in the bad companies to work for. In truth, I wouldn't wish a bad company on anyone, not its customers nor the employees who don't know any better. Everyone needs to know; so that they can make their own choice as to how to react in the interview. With my own first bad interview, they approached me in an assertive aggressive stance with the words "That was your old life, this is your new life with us (ripping up my CV/resume and yelling out an insulting sum as a salary) and how we define your life". People who don't believe in themselves might feel bullied, I stood up and walked out. Don't say a word, you do not want to give them any ammo. Personal agendas can run rife in bad companies, that will only affect your life negatively. Good companies are on the opposite end of the spectrum, it takes a lot to impress me, or leave me awed, and good companies have gone way beyond the horizon of what it takes to do that. When your work is fascinating, it becomes very healthy to free your mind, and be paid exceptionally well for the journey :}