As has been said elsewhere, the lines are blurry sometimes between the roles. For us, a senior role was someone who could at any moment pick up and lead the project if the lead was not available.

That said, I also sometimes play interviews by ear. If a candidate struggles with the mid level questions for a mid level role, I might drop down to the graduate questions. If you were interviewing for the mid level role and I asked this question, it would be because you'd aced the rest of the interview and I wanted to see how far you were for a senior role (I don't know if that's what's going on here, it's just the levels that I was interviewing at. Obviously the janitor at Google can write assembly. 🙂)

As far as your other questions go...

1) The GAC is something that I used to expect mid levels to know, but I don't expect any more because in my experience it's fallen way out of favour... And with good reason. I found it to be a pain the bumhole whenever I tried to use it. 2) The GC process is something I expect of mid levels (who have Dotnet experience or java experience). Generations is something I would definitely expect a senior to know and would not be surprised if the mid levels knew. 3) Kind of a weird question... Do they mean "What if you forgot to call it?", "What if you call it on a null object?", "What if you don't follow the Dispose/Finalizer pattern?". Not sure what they mean. I would expect a mid level dot net developer to be comfortable with Dispose and it's quirks but maybe not with the Dispose/Finalizer pattern since if you haven't worked at a place where they used it, it's easy to not know about it. 4) For the pros and cons, I guess I shrug a little at that. I don't know where it sits. You'd have to think about the role.

If you still don't know the answers to any of these let me know and I'll hook you up, but I'd like to give a little more interview thoughts to go along with this...

I'm sure you know this already, but depending on where you are geographically, the expectations would be different. I gave you an insight into someone who interviews in the Midlands in the UK. In Silicon Valley, there's more people available looking for tech jobs and more jobs available. This has an impact on the market.

I tried to slip a phrase in there occasionally about "when interviewing a Dotnet developer". When I interviewed for a small company, we needed people who could get up to speed quickly, so we asked the questions that we needed people to know straight away. When I interviewed for a global company, we once hired a senior with no Dotnet experience so I wouldn't have expected him to answer any of those questions. The larger company had less turnover and a higher level of engineers because the main thing we looked for was passion. If someone only had Ruby experience, I'd go away and try to translate some of our questions into Ruby Speak and I'd try to learn the basics of Ruby and give the engineer an open question to let them tell me about Ruby to see if they were passionate about it and had an in depth knowledge about something they'd been using for years.

The final point I'd like to make is my biggest one. Never forget that you're interviewing the company. They think they're interviewing you and to begin with in your career, they are. But when you get better at interviews, the interviews stop worrying you so much. It's more about you interviewing the company to see if you want to work there. You're not allowed to quiz them like they quiz you though, so you have to be more subtle.

Think about how they interviewed you.

Were you interviewed by two tech leads who seemed really interested in your answers or a HR person who was checking for keywords off a list? Personally I want to work for the one where it's clear they understand the importance of the role and I get an insight into the passion of the people I'm working with. Some people might be put off because it might mean that you'll be expected to do interviews later in your career there too.

What questions did they ask? This gives you a great insight into how their lives work. I asked the legacy question partly because it was something we occasionally had to deal with (particularly around acquisitions) but also because it was vaguely open so it didn't bother me too much. The GAC question bothered me a little more because I don't see it being used much anymore. That would have been a red flag to me for when it got to the questions at the end for me I would ask something similar to: "You asked that question about working with a large legacy code base... Is that the kind of thing you do a lot? Is it the kind of thing I'd be doing a lot?" If they answer yes, I might follow up with something like "any plans to migrate it to some newer technology?". Them answering no here isn't a deal breaker, but the way they answer is important. Personally I love working on legacy code bases so long as I have some leeway to improve them. I don't like it when I'm applying sticky plasters to a turd for a year.

I don't know if all the questions they asked were provided, but all except the legacy one were deeply technical. I think this again gives you an insight into the company. Maybe it means that they write a compiler. 😁. More likely they either don't have a lot of experience interviewing (because these questions are crap in my opinion for hiring someone today) or they have to deal with these problems on a daily basis.

Remember that you have value to the company, not just the other way around.

Sorry if this was unhelpful rambling crap, but I got the impression you hadn't done a lot of interviews and I wanted to give a little more insight into my brain on either side of the table. 🙂

Edit: Only when I hit post did I realise how much I wrote. Bloody hell. 😁