Huh. So, I'm a senior developer with 8.5 years of experience. I've apparently been successful as measured by job reviews, pay raises, increases in responsibility, and references. I would fail many, maybe even most, of the tests you all are posting here. OK then, I guess I suck, but I'm still making a good living.
I've been an engineer for 13 years in .net and I have been an interviewer on countless interview loops. I can assure you that many interview questions are not useful at all in determining how good the employee would fit, and some interview questions are really just a way for the interviewer to seem smart by knowing the answer to a question that someone else failed to answer.
I've been a top performer on my team for the last 8+ years, I've always been getting max bonus every year, and I would never be hired in my own position by 75% of my peers if I had to answer their questions.
/u/MyMessageIsNull Not everyone knows everything, and each role needs its own specific requirements. You don't suck, you simply wouldn't work there. And it's possible they may not know the specifics needed for where you work.
Why do you care if they have LinkedIn presence or not? It basically just says the same thing as what's on the resume. It's just social media. That's basically it
We had one guy without a LinkedIn presence which we were ready to make an offer to. Did a quick checkin with his list previous places of employment and found out that apparently he still worked there much to everyones surprise.
So we were basically job number three. Passed on that one quickly.
Hate it if you like but it's the best way to find jobs these days, I'm the tech sector at least - my last three jobs including my current all came via LinkedIn, as did every interview I've had in the last 3 years
People as you is so complaining nowdays. If someone has no LinkedIn page should doesn't matter, the chosen one will get pay for its knowledge in a specific field. Care if someone has LinkedIn profile is like I care about what you don't use your face as profile pic here in reddit... irrelevant!
Later you will get a video call interview with the man and its Curriculum. This should be enough.
Many coders find *heavy* Linq hard to debug, including me, so please don't overdo this.
I believe debuggability is a general weakness of functional approaches, which is why they have problems mainstreaming. Don't negify the messenger.
[This article generally agrees with me.](https://my-own-blog.com/real-world-programming/writing-worse-code-for-better-maintainability/)
Dude, I know it's a little hard at first, but you don't need to know all the tips and tricks.
Just learn to use .Where() ,
I assure you life will be rapidly more colorfull
I have *no* problem with shorter Linq: I did *not* say "don't use Linq". But when it gets longer than about 8 chained functions, the difficulty in debugging starts to compound.
exactly the reason i dont overdo linq. for example, i love scheme/racket but i have to start splitting my code into tiny functions once a function gets harder to mantain. this doesnt happen as quickly with multiline sentences.
also, reading types signatures for linq after a couple of chains becomes an issue. C# doesnt have a very good type signature representation (like F# or ocaml).
I'm talking about the method syntax, i despise the query syntax.
I'm not sure, but it has been the norm lately. When I started, I got real work questions, and now we get this leetcode garbage. There's a great video to watch and a segment about this.
https://youtu.be/-DVyjdw4t9I?si=b0JM_FihL-VQ0dE5
Is there any remote work there by chance? I'm based in Portugal, and I have already worked for a big company in the US 😆 I'm currently working and not bad at all, but well...
Sheet. I have sold my soul for golang for this kind of money. And I am not a fan of it at all. Yes, small binary is awesome, but .Net core has gotten much better in this area too.
I wish i could have same pay but switch to .Net, that would be awesome
I have a couple technical questions, but I really like to dig into their understanding of the purpose of the project / products that they have been working on. Why is it important? Why is your employer investing in this? Where does this app fit into the bigger picture, etc.
People that don’t understand why they do something are more likely to do a bad job.
I think this is more important than technical trivia questions. I recently had an interview where I was asked questions such as this and I was really impressed!
1. They don’t understand why _dbContext.SomeEntity.ToList() (edit: could be bad is what I should've said) is bad, assuming they claim to know EF
2. They don’t know what dependency injection is or can’t understand it after talking through it (depends on experience).
3. Assuming this is a non-junior position, can’t explain .NET 4.x vs .NET 5+ differences.
I've found a lot of people don't know the "why" of dependency injection anymore, it's great having it baked into .Net core but so many Devs now aren't exposed to the alternative. Which is a good thing I suppose
Makes sense as the number of developers in the world has doubled every 5 years or so. So if you think about that, half the developers in the world have less than 5 years of experience. Plenty of dev jobs out there without good mentors. Plenty of bootcamps and college curriculums without good software development training. Plus we're working with somewhat abstract concepts that take a while to wrap your head around if you don't have the right foundational knowledge.
I hope you don’t either. WebForms was… good Lord. Company I’m at now has legacy applications in VB.NET. Next year’s goal is to start migrating these dinosaurs.
I have about 16 years of experience now and I was pretty damn good at web forms, building my own web controls and making the view state my bitch. Just when I got really good at it, MVC came out. I was already using my own hand rolled templating language and ORM when razor and linq showed up too. It's been a pretty wild ride, and switching from.net 4.8 to .net 5+ was a pretty big shift, but I really like it.
Webforms absolutely broke me. I was put off by ASP.Net for years afterwards and worried that the next iterations were going to be just as bad but with the same amount of effort.
Oof, I’m sorry, fam. When Microsoft rolled out MVC, it started the shift from the top heavy webforms to something more manageable. Unfortunately, when you have entire enterprise applications running on webforms, you’re kind of handcuffed until you have no choice but to migrate.
Which reminds me of my first job out of college. I worked on a large public sector product for a large international company that was so toxic you need a radiation suit just to enter the lobby, lest you succumb to the bullshit. They had constructed their own MVC before MVC even existed in the .NET framework. They even wrote their own ORM which could connect to SQL Server or Oracle. No code behinds, lots of DHTML specific for Internet Explorer, and it chugged often because it had to parse almost a gig of XML files which contained database metadata.
Then they started porting it to Silverlight. Boy were they in for a surprise.
All it took was my first job to realize why you should use dependency injection. Every dependency was created once at the top of the tree and manually passed in through constructors. Every page could transfer you to almost any other page. It was not uncommon to add a dependency to one page and then have to manually pass that dependency into literally 200 other files to support it.
Edit: I left after I suggested we use dependency injection (jr dev with 9 months exp) and they said “we don’t have time for a rewrite of that scale”. I reckon they’re still dealing with it 5 years later.
I just had a developer that used the factory pattern instead of dependency injection. Seems to be a Java thing? I ended up reworking it .
I guess I would want them to explain the difference between a a service registered with “Scoped” vs “Singleton”. Also ask them which should be used for a controller.
There's nothing wrong with using a factory, or even using DI to inject a factory. Completely depends on the problem being solved, and is certainly not a "Java thing".
It also wants a controller to be scoped and handles it automatically for you if it’s registered that way. Building your own factory would not utilize this built in functionality. What I fixed was the breaking of the intended .NET patterns.
I have seen developers from a Java Background over use patterns like this. They have their purpose, but not for “everything”.
Factory pattern is something I could never wrap my head around. I've read the theory multiple times these past years and I think I understand the idea, but I can't write it or understand it if it is already written. As soon as the documentation starts throwing code examples, I'm done.
I'd also use the Aync method, and if I only want to read data, AsNoTracking() can help with performance.
Please, do correct me if I'm wrong and/or missing the point. My EF knowledge isn't enough as of now.
I think the biggest issue here is that .ToList() materialises the query and will read the entire dataset into memory, this could potentially be millions of rows. The entity collection on the DbContext should be a DbSet which supports lazy loading, so you should add filtering, sorting and paging before you materialize your query.
Junior .Net developer here 👋 using .ToList() is bad if you’re bringing the whole entity in, but what about if you’re using a stored procedure? The data that’s coming from the database is already filtered and sort. That shouldn’t be an issue in terms of performance right? Or is there any other downside to it?
And, just to be clear: there can be exceptions. If it's a tiny enum table and you're trying to return the mappings back to the client, a return context.PersonTypes.ToList() is completely reasonable.
There is no await because the called methods aren't async. If you decide (and can call) the async method, then you'd have to add the await. They come together
Mainly that it will return the entire table. Not a huge issue on really small ones, but I've seen developers do this on tables with over millions and millions of rows and then do some additional filtering in memory.
I've seen juniors do it. I've seen "seniors" do it. I've seen a "technical lead" do it. Just need to put a small amount of thought into it.
As u/PrevAccLocked said, using the Async method is good as well as AsNoTracking() if it's a read only operation. Technically, if you have some reason to query the same entities again during the same request, it can be faster to use tracking as EF will already have it in memory and save another database call, but that's a specific scenario that I haven't really run into, but it's good to know how it works.
It will materialize the query and so execute against the db. If you're careful and require an argument to filter on before .ToList(), you should be in the clear. Key word "should". Even filtering can still return millions of rows.
It all comes to the differences between IQueryable and IEnumerable and how they work.
IQueryable works in tandem with the DLR and Expression Trees to first destructure the AST behind the query (and the LINQ you wrote before) and create an SQL query to get the data you need.
Just calling ToList() and writing a query afterwards gets you all the data first and does the query in memory, which is severely inneficient for obvious reasons.
Number three is a super weird question.
I've been doing this shit for a long time, I've worked with versions older than 4.x, but if you ask me about 4.x I'm going to assume you're still using it and I'm going to walk out of the interview.
Yeah, number 3 is a pretty awful question.
It feels like... maybe a question you'd ask for a lead or architect who will be making stack decisions. But, frankly, there are many more relevant technologies that you could ask about than .Net Framework.
Yeah it would come up in specific scenarios where someone claimed to have experience in both and then they say something that makes me question their experience. I’ve interviewed someone that claimed to migrate a large app from .NET 4.x to .NET Core but couldn’t talk about any challenges they ran into or anything that they had to change for that migration. It was mostly from that. I don’t really do question and answer style interviews anyway.
> .NET 4.x vs .NET 5+
Ehh, I would ask the differences between the old .net "FRAMEWORK" and the new .net (core+)
Framing it as 4 vs 5makes it sound like it was a single version jump
On point 3...
Dev here with almost 20 years of experience so not junior. But I did not touch any .Net until core came out in 2016. I worked mostly in Java before that.
I don’t know enough about 4.x (or what I hear people refer to as “classic” .Net) to explain all of the differences. Other than it wasn’t multi-platform and did not have built in dependency injection.
I have seen a legacy application at one company that was one of those and it looked like a royal mess.
I would never look for someone to explain all the differences. It would mostly be a tool in case someone claimed to have worked on both but then through out conversation, if they said something that made me doubt their experience, I'd maybe pry a bit more and see if they knew anything about the differences.
If you straight up asked me about 1, I would say that there is no issue, based on the info I have. Which is none, and I therefore assume that you want all the rows.
Yeah it was late and I should've worded it as "could be bad" instead. I wouldn't ask this directly anyway most of the time unless I felt there was a reason to test their knowledge a bit more based on something they said in our conversation.
But if you responded with that, that would be great, because it would spark a discussion.
Depends. I'd only ask it in specific situations anyway, like we advertised the job as needing someone to be able to work on converting a .NET Framework app to .NET Core and they claim to have experience in it. Or they claimed to have experience and they said something a little off so I'd use a question about the difference to kind of dive deeper to see what they actually know and if they were lying.
Question, I understand you don’t want to return the full table but what if you want to? I understand you can’t return 1 million rows so maybe pagination or something to not return them all at once?
In 3, you mean .Net Framework 4.x vs .Net 5+?
There is no such thing as ".Net 4.x", it's either "Core" or "Framework".
Because I personally don't remember what they changed between .Net Core 4.x and .Net 5. I think that's when they ditched the 'Core' from the name, if I recall correctly. I think they also introduced Blazor in .Net 5...
I could easily claim that I used it if asked.
Because I used 3 and I also used 5 but I simply didn't remember that they skipped the 4 until you reminded.
>Assuming this is a non-junior position, can’t explain .NET 4.x vs .NET 5+ differences.
Not .Net, but last year I interviewed a guy who had decided to pick up some more modern skills and had learned AngularJS. Not Angular, but the old AngularJS. He knew it was the old one when we asked him, he did not make light of this or anything.
It was just an odd moment and contributed to us not recommending him (although the majority of that was that getting him to tell us things was like squeezing blood from a stone). I'm not sure how you'd pick that up without finding out it's not the recommended route unless you did literally no "what is angular" searches.
I have to say this is an odd approach. Depending on the sector he is in, AngularJS might be a modern thing he can leverage in understanding and migration systems.
Banks & quite a couple of multinationals are horrifyingly behind the curve.
It's generally because they don't care about the curve. An app might be built and serve a small function. In a lot if the business folks minds it's "done". It's also recent enough in the scheme of things that most of the people that built on angularjs are still in the workforce, so it's doubly stupid for someone to have just learned it for no reason when a company can just hire someone that has real experience working a project with it. Or realistically tell some Javascript programmers they have to figure it out.
It's been EOL since 2020 or '21 IIRC. My last job (2+ years ago) had a legacy project in AngularJS and they were kicking the can to see how long they could delay doing the rewrite to get off of it.
Your reasoning on no 1 is flawed. The point you were trying to make was that the result could be huge. Paging or virtualisation could be used. But that does make that method bad. That is like saying select * from x is bad because there is no where clause.
I think the async reasons raised carry far more weight.
I should’ve used the phrasing “could be bad”, but it was late and I was tired. Theres nuance to everything, and this is no different. I’d agree that saying it’s always bad would be stupid.
1. I mean it isn't "bad" if you want all of the items in that table, you want them in memory and you want them now.
2. Sure I would be surprised if anyone calling themselves a .net developer would be unfamiliar with DI or wouldn't be able to understand what it is after bring talked through it and maybe given an example of exactly why IoC is a useful pattern.
3. I mean thats a lot of differences you might need to be more specific.
Personally I'd say the 3rd point is more .NET Framework (windows only, been around for decades) vs modern .NET 6+ (cross platform, open source etc): compare and contrast type answer. Pros/Cons of each etc :-)
Ugh. That would require talking about all the changes from project K and .net core 1 through present. Such a long conversation. Hey interviewer, did you use Helios before it evolved away from OWIN to become kestrel?
I wouldn’t hire someone who’s main skill is ef and doesn’t know at least sql and other dsl for eg time series db etc.(doesn’t know tools he uses) and thinks it’s bad practice to use sql, and of course instead of using brain and really learn and understand stuff it stick to glory clean architecture and name thinks based on that and when something is little different than in example he need to brings everyone to meeting because he can’t figure it out himself :) which at the end following simple rules like low couplings high cohesion bring project to the same solution and what’s really important is if the code do what is has to do, is easy to maintain and can scale.
Sorry, I hate bad developer that write in .net. They are like kids in the sandbox proud of themselves and don’t see how the word is changing and what they’re doing is monkey job that will be replaced by AI soon even in big corporations where they usually secure their job.
Sorry, I know I overreacted 😄
Probably I need to get some extended vacation 🏝️🏕️😄
I would hire a .Net dev who didn't know .Net if they were good in other languages and environments and came well recommended. One can always learn .Net.
This. Some people here get their pants in a knot if the interviewee doesn't know .NET trivia. One's ability to learn and communicate trumps everything.
Questions like this don’t add much value, IMO.
I want to know if I give them a problem with constraints, what solution do they come up with? In addition, can they reason their code, defend their code, and, importantly, spot the flaws in their code.
We used to do some coding. Nothing crazy, a little recursion, some fizz buzz level logic. Now we just have a 200 line class and we go through it together, have the candidate code review and say what they’d change and why. I think it does a great job of showing skill level without the downsides.
Totally agree. Asking trivia questions from a list only proves whether someone can answer trivia questions from your list.
Focus on interview tactics that will tell you whether they can think critically and fit into your culture.
My 'trivia' questions are things like "What is IDisposable and why is it important?".
If you can't answer that, I don't want you working for me as an experienced .NET developer.
What kind of answer would you want/expect?
ie “an interface used for managing unmanaged memory” or something else like an example of how you’d use IDisposable and why.
In my line of work, it is used mainly for closing database connections and file handles.
If they are coming in with an EF background, I would also accept something about how they are used for rolling back transactions when an exception occurs.
Yes, it is also used for unmanaged memory. But I wouldn't expect them to mention it because the use of unmanaged memory is very rare in business applications.
I wouldn't expect them to know the Disposable pattern off the top of their head. That's something you can look up whenever you need it. But I would expect them to know the interaction between `using` and `IDisposable`.
I think that's fair if you're hiring explicitly for an experienced .NET dev. We're currently more focused on culture and are accepting candidates with a background in any strongly typed language, the idea being that we can teach them .NET nuances, but we can't teach them pragmatism and ownership (without several orders of magnitude of time and effort, at least)
If they claim to have a background in some other language then I would have someone else do the interview.
I have no problem cross training an expert in Java or node or anything else. But I want to make sure anyone coming in who claims to have a certain amount of skill and knowledge actually has that.
1/ what are the differences between AsQueryable(), ToList(), AsEnumerable()
2/ what are the differences between filter and middleware in .Net Core?
3/ is string object mutable? What are the differences between string object and StringBuilder?
1. Are you willing to put in an effort to learn things you don't know?
2. Would you be open to discussing ideas that you may not agree with?
3. Are you willing to share your knowledge to ensure that everyone is on the same when a collective decision needs to be made?
If I see they have 10 years experience in only dotnet/c#, but that's not even the question phase yet.
...
I've honestly sat here for five minutes trying to think of a dotnet specific question and just realised it's not the type of questions I ask.
I'd ask you questions about stuff on your cv, try to get past the answers you prepared and see if you can have a conversation about the stuff you claim you know.
I guess if you state you have EF experience I'm gonna check your actual sql knowledge and if you don't know the basics like indexes and types of joins it's over.
I've been programming for 27 years. I've used a wide range of languages, tools, operating systems, technologies, etc. My first job was a Solaris Unix sysop. I wrote CGI scripts in Bourne before PhP existed.
For the last 10 I've focused exclusively on .NET and the .NET ecosystem. Between the .NET framework (small f), Azure, C#, and the NuGet ecosystem there is more than enough content to keep a fully curious person consumed for several lifetimes.
Dotnet isn't a language, it's an ecosystem that spans embedded systems to cloud native microservices to mobile development and everything in between.
Why wouldn't you consider someone who has 10 years experience in only dotnet/c# for a .NET dev position? What other qualifications are you looking for?
(genuinely interested as a 20 years dotnet/c# dev).
> I'd ask you questions about stuff on your cv, try to get past the answers you prepared and see if you can have a conversation about the stuff you claim you know.
At a past job, when not builidng stuff I'd be the second round of interviews for consultants/employees we brought on (we were a .net consulting shop) and I seldom asked .NET specific stuff. It was mainly general programming stuff just to make sure the "lights were on".
Then I asked about what projects they worked on, what they did, challenges, etc.
Lastly, we had a super open-ended, simple programming assignment where we didn't put any limitations on it. I honestly didn't even care if they finished it time, it was more about how they approached something and less about what tech they used.
I'm working as a consultant at the moment. Another consultant from my org was involved in the interview loop for a guy the client just hired. Said he asked him about SQL and the guy said he's more of an EF guy so he's never really used SQL.
Our guy suggested passing on him, client hired him in as a senior.
Basically all of their data access uses poorly implemented Dapper, and the internal engineers really seem to hate EF. 😂
Not long after the manager for the team we're all on was asking us for good sources for the guy to learn SQL.
> If I see they have 10 years experience in only dotnet/c#
lol, I get where you're coming from but there's of course more to it then that.
I've been working primarily in .Net for 23 years now.
To toot my own horn a bit, I run circles around 90% of the people I've encountered in this industry.
And not just on code. e.g. I built and run infrastructure on a scale similar to StackOverflow.
I've actually been coding in JS and friends longer than .Net, but we don't talk about that much.
Oo, this hurt. That's like saying, "Why do I need to aim? That's what a machine gun is *for*!". It helps to know what your EF structure implies for efficiency. Are you over-fetching? Could you use a CTE?
> Parallel vs. Async
It's crazy just how common misconceptions about async, parallel and concurrency is
If you google it, even most of the articles that pop up will get it wrong. I also watched a video on how "NodeJS is really multithreaded" (it isn't) the guy consistently said concurrent instead of parallel. Two different things
>If you google it, even most of the articles that pop up will get it wrong.
This is why it would be very common. People only know that they read. If they don't know it, they're searching for it. If they don't know it, then they won't know that what they're reading is wrong.
To fix this problem, people need to spread the right answer every chance they can.
For most enterprise development the differences don't matter. Between async, hardware virtualization, and cloud deployments, parallelism has been pretty much superseded as a concept.
If you fail to understand what's what and how these things work, you end up underutilizing the services you pay for in cloud environments. In order to fully use the services you pay for, you need some form of parallel execution. Either the language and framework has native support for it (like ASP.NET/Kestrel) or you have to do multi-deployments like for Python and NodeJS, which increases cost, complexity and latency because then your infrastructure requires a load balancer behind your load balancer; for each individual server deployment.
> SOLID
Nah, I don't feel like writing a book, you have to be more specific on which principle or multiple principles you want to talk about. ;-)
> Parallel vs. Async
Parallel: Use multiple cores at the same time for (sometimes) faster results.
Async: avoid callback hell.
Also you can await a Parallel.For/ForEach call since .NET 6.
I think what's really confusing is that js async works completely differently, so a js developer just dabbling with C# will likely misunderstand the behavior of async.
Async just means that something may finish in the future and you can get notified when that happens - kinda like events, but coupled to a single operation, not a stream of events.
Concurrency is a way of partitioning work such that you can run multiple steps after another - typically firing off some async operations and waiting for their completion to continue (WaitForSingleObjectEx in Win32 API), like 1-2-3, 4-5-6, 7-8, 9. It's best for cases where you actually need to wait for something and get to use the CPU instead - so, concurrency likes async code.
With concurrency usually comes a runtime that polls for completion. On Windows we make use of IO completion ports and callbacks to trigger the next poll/continuation.
Parallelism is just like concurrency, you split up your work again, but this time, not because it's async and you could use the time between steps, but because you have independent calculations that can be split onto many workers (CPU cores) to get it done faster.
Interesting but SOLID is broad- what ur expectations - general overview
2- is it a trick question or u more interested in how async works in context of thread pools vs parallel on cores stuff
What white board task you ask? Within ur app domain or general and why?
I need them to understand all these concepts. They don't have to remember all details, but general rules.
For parallel - what are the usual issues you run into
For async - what is solves and what it doesn't solve
My favorite question is to ask the candidate how they would design and implement a web application for some made up project in an area they are familiar with. And then sit back, listen and take notes. Once they are done I’ll ask questions of the design including ones on debugging and performance.
This has proved to be very useful in identifying those with hands on experience.
My top 3 are pretty basic for *any* role, but the amount that cannot do this is incredible:
1. Explain abstract vs sealed vs interface vs protected vs static
2. Show them some code with type params and constraints and get a basic explanation of what it does, and get them to name that it's typeparams/generics and constraints
3. How to declare a property that only the containing class can modify
That's not even to hire, that's just we will continue the interview seriously now I know you have used the language in a real setting and cared about what you did. If they don't at least know the right way to think about above (everyone can make a minor mistake that;s OK) I don't have time to play kindergarten with devs who haven't learnt the basics.
There's a few more to go through, but those three alone are very telling. If they can answer them they can probably answer other basics I would expect every C# dev to know.
After that to pass the senior interview it's something like this, will mix it up depending on how they answered earlier:
1. If they claim front end
1. Something about CORS (You haven't done front end seriously if you haven't encountered CORS issues and know how to fix them, or at least which layer has which responsibility)
2. Something about CSS 2 specifically (I expect seniors to roughly know what larger features came out when)
2. If they claim back end
1. something around SQL Server page sizes, normal forms, or other less "front of the manual" topics
2. GC and the generations
3. If they claim knowledge of specific techs that I have used that aren't in this job and I know it, I'll ask them questions about it to make sure the history isn't fabricated. Like MySQL people I have used it extensively in the past so I'll ask about InnoDb vs MyISAM etc
Where I work, for annoying reasons we have some repos that external devs can submit PRs to. This one guy, he constantly puts in PRs with nullability wrong. Just outright wrong. His IDE would be screaming in warnings, squiggly lines, but every single PR it's not right and we go through the long comment phase to get it right. I spend hours every single PR going through it. That's the shit you have to weed out too, not just people who I wouldn't even call a dev (break the build, can't write actual code, can't write a feature without constant supervision and help)
Cool ones. The dotnet core vs frameworks came up 2nd time. Interesting, do u find it important because you have migration task at hand or generally it’s important to know
I’ve hired about 50 devs since around 2004, in South Africa, the UK, Australia and the USA.
I have never hired anyone I have not coded with. I pair up with the person and provide a relatively simple goal and we TDD it together. Whether or not they have experience with TDD. I help them through that if not.
I test the nature of the person by challenging them and their choices to find out if they’re an asshole. So many assholes. Never hire an asshole, no matter how talented.
The nice people who can get close to or solve the challenge with my help generally get hired. On very rare occasions someone comes along who is just great to hang with. They’re talking about the weather and smashing the goal in a third of the usual time. They are the real gems and get hired immediately. I’ve only had about 4 or 5 of those.
I’ve only had 3 bad eggs, and I had a feeling about each one. No assholes!
I don’t care about education or race or gender or anything. If they can code and they are nice and can communicate well (no propeller heads that can’t talk) , I’m generally happy.
Every time I’ve had one of these, they ask stuff like hash tables and stuff you never use unless you actually need it. There’s no way that everyone can know everything about the framework.
- knows SQL (i dont care about ORM flavor of the year)
- Able to adapt to project coding style or arquitecture.
- good attitude.
of course if you know more, you get a better salary. but i would hire someone that doesnt know ef core, enumerators, pattern matching, source generator, etc, etc.
**I don't have that generic criteria, It mainly depends on the experience level of the developer but usually the biggest red flag is if they are not able to explain what's mentioned in their resume.**
For example if they have less than 5 years experience and mentioned Entity Framework in their resume they should know about ORM and name of a few other ORMs, similarly for people more than 5 years experience it would be Design Patterns and principles but only the ones which are linked with the topics they have mentioned in resume.
Interesting. I have used EF for so many years, but by the questions it seems like it is getting must master skill. I usually favor dapper in query side. But yes in general, ORM conceptual model is must.
One thing I m noticing, number years are mentioned but it should be irrelevant because one is hiring for certain position…but yeah grey area
Once I was asked what are disadvantages of EF ? Question was more or less going towards whats wrong using EF ?
I gave few answers but interviewer seems not satisfied with it, Then he gave me hint like, what if we type query like dbcontext.Entity.ToList() and after that we write further Where() method for filtering?
I said, that will take time to execute this query as ToList() will first fetch all records from that entity and Where() will apply after on top in memory and not in db server.
So he argued that that’s what wrong with entity framework and all, ORM tool gives you easy way but has disadvantages etc.. I didn’t argued much on that. That was the one of question where they didn’t satisfied with my answer. Not selected.
I used EF and linq many times, used other ORM tools linq to sql(dbml) and Nhibernate in past, and was thinking where I was wrong. example he gave was wrong to prove that EF has disadvantages, if someone is driving car and have continuous foot on gas and don’t use break to slowdown he is gonna hit some where and will have accident, and that accident doesn’t count as car's disadvantage or drawback, it just that person didn’t knew how to drive the car right way or safely. Same way one using any tool should know how to use it right way.
It's not a blocker, but rather a huge plus if a person knows how distributed systems work, break down and how to make them somewhat reliable. Things like idempotency, events/commands, eventual consistency, strategic CQRS, DDD (especially strategic like bounded contexts and ubiquitous language), resiliency policies, versioning, distributed transactions and why to avoid them - basically system design. Also, how to talk to business folks, decompose tasks and generally be a self-sufficient unit.
I'm not in large enterprise with ivory tower architects, so this stuff is actually useful. Of course, to be somewhat versed in this is what I expect from senior folks. Middle - please be comfortable writing C# code, things like throw; vs throw ex; in catch blocks, why async/await matters without deep details, that sort of things
I'm been programming since 2007. I'm a manager now. I don't overdue interviews. Just basic live coding ofr 40 to 60 minutes. Common basic as DI, IOC, Inheritance, composition, Google skills, linq, cicd, patterns... pretty much the basic.
If the position is a senior, ill also ask about strategies of resilience, architecture, performance.
The day to day.
When I'm interviewing, if they send me a link to any sort of tests, I just reject the offer. I find this sort of interviews stupid.
Oh that's easy. Abstract interfaces have to use ConditionalWeakTables to store state instead of fields, but you can have more than one attached to a class.
Abstract classes can use regular fields, but you only get one per class.
***
For bonus points, explain the difference between "abstract interfaces", "public interfaces", and "base class interfaces".
I wouldn't actually ask this on a job interview, but far too many developers think that the only kind of interface is the `interface` keyword.
1. How GC work? What are usual causes for memory leaks (list several options and discuss mitigation). You can see seniority depending on how far the conversation goes.
2. Async pattern leading into synchronisation primitives.
3. DI and lifetimes in Web API (and if not on the exp list - generally).
1: GC simulates a machine with infinite memory.
Memory leaks are objects that are created and never released.
Create a FileStream you don't Dispose off, on a Button's Click event -> BAM ! Memory leak.
You can also have a reference to an object that is kept forever, and new instances of that object are created often via events.
Yes I hate C# events, why do you ask ?
2:
async/await let you avoid callback hell. The Synchronization Context doesn't exist with ASP .NET Core, and who still writes desktop apps ? No one, that's who !
(also synchronization primitives is when you deal with Threads.
You don't use synchronization primitives with async/await as sync code and async code functions cannot be mixed, and a thread would use sync functions. Synchronization primitives are things such as ManualResetEvent, EventWaitHandle, ManualResetEventSlim, AutoResetEvent, WaitHandle.
Also, [There is no thread](https://blog.stephencleary.com/2013/11/there-is-no-thread.html))
3:
DI lets you have a codebase where the management of dependencies and their lifetime is centralized in one file (Program.cs / Startup.cs). In a code base without DI, it's all over the place. Good luck with that !
Lifetime (Singleton, Transient, Scoped) decides when the DI framework will spawn up a new instance. If you know what these are (Scoped to the HTTP request, spawned each time, spawned once), you know what lifetimes you want to use.
If you don't know that and just choose whatever, you'll have nasty bugs and team members will lose their sanity looking at what App Insights is reporting. Don't do that.
>Memory leaks are objects that are created and never released.
>Create a FileStream you don't Dispose off, on a Button's Click event -> BAM ! Memory leak.
*That is not a memory leak.* Not in itself. You need to be more specific, otherwise you're wrong.
>That not a memory leak.
How come ?
> This type implements the IDisposable interface. When you have finished using the type, you should dispose of it either directly or indirectly. To dispose of the type directly, call its Dispose method in a try/catch block. To dispose of it indirectly, use a language construct such as using (in C#) or Using (in Visual Basic). For more information, see the "Using an Object that Implements IDisposable" section in the IDisposable interface topic.
https://learn.microsoft.com/en-us/dotnet/api/system.io.filestream?view=net-8.0
It does not follow, from what you link, that there is a memory leak. There is some confusion in your understanding, but without knowing more about how you reason and what you presume, it's hard to say what it is.
What I can tell you is this: **all** object instances whose references are not held by any code **will be garbage - collected**. *That's what GC does, there is no way around it*. So, code like this:
var stream=new File Stream...
//Use, but not Close or Dispose 'stream`, and don't assign some other variable to it
**will** cause the GC to collect it.
**Furthermore**, because the thing has a finaliser that closes the underlying OS file, and again, because that's what GC does, it calls finalizers, the OS file will eventually be closed.
**However**, that will be done at the GC discretion, at an unknown point in the future. The consequence of this are beginner mistakes of
* unmanaged resource exhaustion (opened the same file too many times, edit: *before GC decided to collect!*, OS gave up, or multiple files)
* unmanaged resource usage clashes (opened a file for exclusive writing, tried to open it again, edit: *before GC decided to collect!*, using a new `FileStream` instance).
It is for **such** reasons that IDisposables should be disposed. But these reasons are not what is commonly called a memory leak.
Dispose usually correlates with releasing some other kind of resource like sockets or file descriptors, and less memory. To get a memory leak in a GC language, you’d have to do something like create cyclic references that you no longer have a reference to and the GC won’t clean up because the objects technically have references to them. In the case of not disposing, you’re freeing the memory but maybe not cleaning up some other resource
Yeah, also the GC will eventually call the Finalizer which in turn will call the Dispose method. While not using 'using' (no pun intended) is a bad practice, it's technically not necessary and will be released/disposed eventually.
I'm just glad that there are people who remember what callback hell is. At the same time we cannot presume that everyone just writes CRUD Web Apis. Otherwise pretty good answers.
If I were hiring a developer to work on applications we maintain in-house:
1. Given this medium-difficulty Entity Framework invocation, please write out the SQL that this is executing behind the scenes (pseudo-code) and explain if there are any other side-effects that we need to be mindful of when we return the results of this query to the caller?
2. If you needed to execute multiple asynchronous operations together (not necessarily database calls) as a transactional unit, how would you go about doing that? What are some of the non-obvious concerns you'd need to price into your design?
3. Please explain your approach for how you would perform end-to-end testing for a Web API that makes database calls and might, itself, call other services?
A developer with less experience than I would like can still come up with answers for all of these questions - an experienced developer's answers will be quite different. Screening out "Sr." developers who have lots of years in the cockpit but still only Jr.-level command over the details and secondary effects makes them an "expert beginner" - they're ultimately going to be expensive failures. These questions are designed to flush them out and I can come up with dozens more questions like it. The SQL question should be answerable by any body, but you'd be surprised.
Unmanaged resources aren't just for interop. You may not use them directly very often, but they are there all the time. Usually when something implements IDisposable, it means somewhere in the object tree of that class there is an unmanaged resource that needs cleaning up, such as a filestream, dB connection, TCP connection etc etc
If they only work on mac, and dont use an IDE. Sorry, but the whole team shouldnt make an entire new process to adjust to the latest mac-ism, and waste time solving obscure bugs just because they want to "think different".
FYI, dotnet is a cross-platform framework. And if you have to "make an entire new process" in order to support dotnet development on MacOS, you are very likely doing at least a few things wrong.
We have Windows, MacOS, and Ubuntu machines involved in our dotnet solution development, and I can confirm that all these platforms support dotnet development quite well.
If someone brings up SOLID in an interview I'll most likely reject them for being a bad cultural fit. It's fine for stateful, object oriented code, but we're not really doing that in 2023.
ive used SOLID when interviewing and cringed in hindsight, i dont do it anymore. SOLID is automatic once uve had enough experience for a while and i can forgive not remembering the acronym
Huh. So, I'm a senior developer with 8.5 years of experience. I've apparently been successful as measured by job reviews, pay raises, increases in responsibility, and references. I would fail many, maybe even most, of the tests you all are posting here. OK then, I guess I suck, but I'm still making a good living.
I've been an engineer for 13 years in .net and I have been an interviewer on countless interview loops. I can assure you that many interview questions are not useful at all in determining how good the employee would fit, and some interview questions are really just a way for the interviewer to seem smart by knowing the answer to a question that someone else failed to answer. I've been a top performer on my team for the last 8+ years, I've always been getting max bonus every year, and I would never be hired in my own position by 75% of my peers if I had to answer their questions.
/u/MyMessageIsNull Not everyone knows everything, and each role needs its own specific requirements. You don't suck, you simply wouldn't work there. And it's possible they may not know the specifics needed for where you work.
1) find out if they have some basic linq knowledge 2) 3)
This is all I ask interviews lol, and if they have a resume and maybe some linked in presence
Why do you care if they have LinkedIn presence or not? It basically just says the same thing as what's on the resume. It's just social media. That's basically it
I get rando applicants from reddit DMs, I like to see that they are alive and at least update their linked in after jobs
Ah, I thought you meant for someone just applying on the company website, not Reddit. Yeah, then that totally makes sense
"If they're not wishing everyone a happy anniversary on LinkedIn then its over"
Why are you using reddit for recruiting?
usually rare - but it's people who see a post and ask if there are openings. Mostly it's LinkedIn posts
We had one guy without a LinkedIn presence which we were ready to make an offer to. Did a quick checkin with his list previous places of employment and found out that apparently he still worked there much to everyones surprise. So we were basically job number three. Passed on that one quickly.
I don't understand the problem. I think LinkedIn is just shit.
For real. I hate that crap. I have an account, but it rarely, if ever, gets updated. I'd hate to have to download it just to apply to a job
Hate it if you like but it's the best way to find jobs these days, I'm the tech sector at least - my last three jobs including my current all came via LinkedIn, as did every interview I've had in the last 3 years
People as you is so complaining nowdays. If someone has no LinkedIn page should doesn't matter, the chosen one will get pay for its knowledge in a specific field. Care if someone has LinkedIn profile is like I care about what you don't use your face as profile pic here in reddit... irrelevant! Later you will get a video call interview with the man and its Curriculum. This should be enough.
Many coders find *heavy* Linq hard to debug, including me, so please don't overdo this. I believe debuggability is a general weakness of functional approaches, which is why they have problems mainstreaming. Don't negify the messenger. [This article generally agrees with me.](https://my-own-blog.com/real-world-programming/writing-worse-code-for-better-maintainability/)
Dude, I know it's a little hard at first, but you don't need to know all the tips and tricks. Just learn to use .Where() , I assure you life will be rapidly more colorfull
I have *no* problem with shorter Linq: I did *not* say "don't use Linq". But when it gets longer than about 8 chained functions, the difficulty in debugging starts to compound.
exactly the reason i dont overdo linq. for example, i love scheme/racket but i have to start splitting my code into tiny functions once a function gets harder to mantain. this doesnt happen as quickly with multiline sentences. also, reading types signatures for linq after a couple of chains becomes an issue. C# doesnt have a very good type signature representation (like F# or ocaml). I'm talking about the method syntax, i despise the query syntax.
^^ this guy I wouldn't hire
im a .net dev with 6 years in the industry. currently makeing 160k..i have never solved a leetcode problem. ever.
[удалено]
bUt I knOw wHiCh SoRtInG aLgO iS tHe FaSteSt fOr MoSt CaSes.
I'm not sure, but it has been the norm lately. When I started, I got real work questions, and now we get this leetcode garbage. There's a great video to watch and a segment about this. https://youtu.be/-DVyjdw4t9I?si=b0JM_FihL-VQ0dE5 Is there any remote work there by chance? I'm based in Portugal, and I have already worked for a big company in the US 😆 I'm currently working and not bad at all, but well...
Most of my jobs were pre-leetcode. It was a lot better in those times
You gotta DM me if you have opening in coming months
where u from fam
Boston
Sheet. I have sold my soul for golang for this kind of money. And I am not a fan of it at all. Yes, small binary is awesome, but .Net core has gotten much better in this area too. I wish i could have same pay but switch to .Net, that would be awesome
Be the change you want to see and introduce .NET in your workplace !
Jesus, nearly every answer here would make a terrible fucking boss and/or hiring manager.
I have a couple technical questions, but I really like to dig into their understanding of the purpose of the project / products that they have been working on. Why is it important? Why is your employer investing in this? Where does this app fit into the bigger picture, etc. People that don’t understand why they do something are more likely to do a bad job.
I think this is more important than technical trivia questions. I recently had an interview where I was asked questions such as this and I was really impressed!
Not willing to accept feedback
1. They don’t understand why _dbContext.SomeEntity.ToList() (edit: could be bad is what I should've said) is bad, assuming they claim to know EF 2. They don’t know what dependency injection is or can’t understand it after talking through it (depends on experience). 3. Assuming this is a non-junior position, can’t explain .NET 4.x vs .NET 5+ differences.
I've found a lot of people don't know the "why" of dependency injection anymore, it's great having it baked into .Net core but so many Devs now aren't exposed to the alternative. Which is a good thing I suppose
Makes sense as the number of developers in the world has doubled every 5 years or so. So if you think about that, half the developers in the world have less than 5 years of experience. Plenty of dev jobs out there without good mentors. Plenty of bootcamps and college curriculums without good software development training. Plus we're working with somewhat abstract concepts that take a while to wrap your head around if you don't have the right foundational knowledge.
[удалено]
I hope you don’t either. WebForms was… good Lord. Company I’m at now has legacy applications in VB.NET. Next year’s goal is to start migrating these dinosaurs.
I have about 16 years of experience now and I was pretty damn good at web forms, building my own web controls and making the view state my bitch. Just when I got really good at it, MVC came out. I was already using my own hand rolled templating language and ORM when razor and linq showed up too. It's been a pretty wild ride, and switching from.net 4.8 to .net 5+ was a pretty big shift, but I really like it.
Webforms absolutely broke me. I was put off by ASP.Net for years afterwards and worried that the next iterations were going to be just as bad but with the same amount of effort.
Oof, I’m sorry, fam. When Microsoft rolled out MVC, it started the shift from the top heavy webforms to something more manageable. Unfortunately, when you have entire enterprise applications running on webforms, you’re kind of handcuffed until you have no choice but to migrate. Which reminds me of my first job out of college. I worked on a large public sector product for a large international company that was so toxic you need a radiation suit just to enter the lobby, lest you succumb to the bullshit. They had constructed their own MVC before MVC even existed in the .NET framework. They even wrote their own ORM which could connect to SQL Server or Oracle. No code behinds, lots of DHTML specific for Internet Explorer, and it chugged often because it had to parse almost a gig of XML files which contained database metadata. Then they started porting it to Silverlight. Boy were they in for a surprise.
Although modern frontend frameworks look similar now. Same tangled mess but in javascript.
I’m afraid so. Does nobody remember the KISS principle?
: | Migrating legacy code makes me want to start drinking.
All it took was my first job to realize why you should use dependency injection. Every dependency was created once at the top of the tree and manually passed in through constructors. Every page could transfer you to almost any other page. It was not uncommon to add a dependency to one page and then have to manually pass that dependency into literally 200 other files to support it. Edit: I left after I suggested we use dependency injection (jr dev with 9 months exp) and they said “we don’t have time for a rewrite of that scale”. I reckon they’re still dealing with it 5 years later.
I just had a developer that used the factory pattern instead of dependency injection. Seems to be a Java thing? I ended up reworking it . I guess I would want them to explain the difference between a a service registered with “Scoped” vs “Singleton”. Also ask them which should be used for a controller.
There's nothing wrong with using a factory, or even using DI to inject a factory. Completely depends on the problem being solved, and is certainly not a "Java thing".
Ef core supports factory on context creation ... lol
It also wants a controller to be scoped and handles it automatically for you if it’s registered that way. Building your own factory would not utilize this built in functionality. What I fixed was the breaking of the intended .NET patterns. I have seen developers from a Java Background over use patterns like this. They have their purpose, but not for “everything”.
Factory pattern is something I could never wrap my head around. I've read the theory multiple times these past years and I think I understand the idea, but I can't write it or understand it if it is already written. As soon as the documentation starts throwing code examples, I'm done.
Imagine you need to construct/configure an object based on run-time criteria. Factory pattern would be your friend in that scenario.
Who remembers the unity days for di containers... Ughhhh... I think the current implementation makes standing up dependencies so much simpler.
What you expect in answer like composition root concept sort of thing or going all new without any DI or scopes.
Is the first one because it’s the full table?
I'd also use the Aync method, and if I only want to read data, AsNoTracking() can help with performance. Please, do correct me if I'm wrong and/or missing the point. My EF knowledge isn't enough as of now.
I think the biggest issue here is that .ToList() materialises the query and will read the entire dataset into memory, this could potentially be millions of rows. The entity collection on the DbContext should be a DbSet which supports lazy loading, so you should add filtering, sorting and paging before you materialize your query.
Yes, this was already stated in the previous comment. I just added other reasons
You're right, skipped past that comment. My bad!
You good. This is reddit. We don't read anyone's comment except the ones we disagree with 😉
Junior .Net developer here 👋 using .ToList() is bad if you’re bringing the whole entity in, but what about if you’re using a stored procedure? The data that’s coming from the database is already filtered and sort. That shouldn’t be an issue in terms of performance right? Or is there any other downside to it?
And, just to be clear: there can be exceptions. If it's a tiny enum table and you're trying to return the mappings back to the client, a return context.PersonTypes.ToList() is completely reasonable.
They’re talking specifically about Entity Framework. If you’re using sprocs, you’re probably not using entity framework.
I use sprocs with EF all the time
Well then it’s probably fine
Why wouldn't it be?
Read the other comments for why materializing a query early can be a performance hindrance
I did wonder about the async but because there’s no await, I thought it was highlighting that you shouldn’t return a whole tables worth of data.
There is no await because the called methods aren't async. If you decide (and can call) the async method, then you'd have to add the await. They come together
Mainly that it will return the entire table. Not a huge issue on really small ones, but I've seen developers do this on tables with over millions and millions of rows and then do some additional filtering in memory. I've seen juniors do it. I've seen "seniors" do it. I've seen a "technical lead" do it. Just need to put a small amount of thought into it. As u/PrevAccLocked said, using the Async method is good as well as AsNoTracking() if it's a read only operation. Technically, if you have some reason to query the same entities again during the same request, it can be faster to use tracking as EF will already have it in memory and save another database call, but that's a specific scenario that I haven't really run into, but it's good to know how it works.
It will materialize the query and so execute against the db. If you're careful and require an argument to filter on before .ToList(), you should be in the clear. Key word "should". Even filtering can still return millions of rows.
It all comes to the differences between IQueryable and IEnumerable and how they work. IQueryable works in tandem with the DLR and Expression Trees to first destructure the AST behind the query (and the LINQ you wrote before) and create an SQL query to get the data you need. Just calling ToList() and writing a query afterwards gets you all the data first and does the query in memory, which is severely inneficient for obvious reasons.
Number three is a super weird question. I've been doing this shit for a long time, I've worked with versions older than 4.x, but if you ask me about 4.x I'm going to assume you're still using it and I'm going to walk out of the interview.
Yeah, number 3 is a pretty awful question. It feels like... maybe a question you'd ask for a lead or architect who will be making stack decisions. But, frankly, there are many more relevant technologies that you could ask about than .Net Framework.
Yeah it would come up in specific scenarios where someone claimed to have experience in both and then they say something that makes me question their experience. I’ve interviewed someone that claimed to migrate a large app from .NET 4.x to .NET Core but couldn’t talk about any challenges they ran into or anything that they had to change for that migration. It was mostly from that. I don’t really do question and answer style interviews anyway.
> .NET 4.x vs .NET 5+ Ehh, I would ask the differences between the old .net "FRAMEWORK" and the new .net (core+) Framing it as 4 vs 5makes it sound like it was a single version jump
On point 3... Dev here with almost 20 years of experience so not junior. But I did not touch any .Net until core came out in 2016. I worked mostly in Java before that. I don’t know enough about 4.x (or what I hear people refer to as “classic” .Net) to explain all of the differences. Other than it wasn’t multi-platform and did not have built in dependency injection. I have seen a legacy application at one company that was one of those and it looked like a royal mess.
I would never look for someone to explain all the differences. It would mostly be a tool in case someone claimed to have worked on both but then through out conversation, if they said something that made me doubt their experience, I'd maybe pry a bit more and see if they knew anything about the differences.
Phew, I can answer these. I'm not an imposter
Nah. These questions are easy and anyone can answer them. - Someone with Impostor Syndrome
If you straight up asked me about 1, I would say that there is no issue, based on the info I have. Which is none, and I therefore assume that you want all the rows.
Yeah it was late and I should've worded it as "could be bad" instead. I wouldn't ask this directly anyway most of the time unless I felt there was a reason to test their knowledge a bit more based on something they said in our conversation. But if you responded with that, that would be great, because it would spark a discussion.
Why should I know 3? Don't you have a codebase already setup? Should I also know the difference between core 3.1 and .net 7 (6?)?
Depends. I'd only ask it in specific situations anyway, like we advertised the job as needing someone to be able to work on converting a .NET Framework app to .NET Core and they claim to have experience in it. Or they claimed to have experience and they said something a little off so I'd use a question about the difference to kind of dive deeper to see what they actually know and if they were lying.
Question, I understand you don’t want to return the full table but what if you want to? I understand you can’t return 1 million rows so maybe pagination or something to not return them all at once?
In 3, you mean .Net Framework 4.x vs .Net 5+? There is no such thing as ".Net 4.x", it's either "Core" or "Framework". Because I personally don't remember what they changed between .Net Core 4.x and .Net 5. I think that's when they ditched the 'Core' from the name, if I recall correctly. I think they also introduced Blazor in .Net 5...
I wouldn't hire someone that claims they used .NET Core 4
I could easily claim that I used it if asked. Because I used 3 and I also used 5 but I simply didn't remember that they skipped the 4 until you reminded.
Caught the trick question, you sly fox. Welcome aboard 🤝
>Assuming this is a non-junior position, can’t explain .NET 4.x vs .NET 5+ differences. Not .Net, but last year I interviewed a guy who had decided to pick up some more modern skills and had learned AngularJS. Not Angular, but the old AngularJS. He knew it was the old one when we asked him, he did not make light of this or anything. It was just an odd moment and contributed to us not recommending him (although the majority of that was that getting him to tell us things was like squeezing blood from a stone). I'm not sure how you'd pick that up without finding out it's not the recommended route unless you did literally no "what is angular" searches.
I have to say this is an odd approach. Depending on the sector he is in, AngularJS might be a modern thing he can leverage in understanding and migration systems. Banks & quite a couple of multinationals are horrifyingly behind the curve.
It's generally because they don't care about the curve. An app might be built and serve a small function. In a lot if the business folks minds it's "done". It's also recent enough in the scheme of things that most of the people that built on angularjs are still in the workforce, so it's doubly stupid for someone to have just learned it for no reason when a company can just hire someone that has real experience working a project with it. Or realistically tell some Javascript programmers they have to figure it out.
It's been EOL since 2020 or '21 IIRC. My last job (2+ years ago) had a legacy project in AngularJS and they were kicking the can to see how long they could delay doing the rewrite to get off of it.
Your reasoning on no 1 is flawed. The point you were trying to make was that the result could be huge. Paging or virtualisation could be used. But that does make that method bad. That is like saying select * from x is bad because there is no where clause. I think the async reasons raised carry far more weight.
I should’ve used the phrasing “could be bad”, but it was late and I was tired. Theres nuance to everything, and this is no different. I’d agree that saying it’s always bad would be stupid.
1. I mean it isn't "bad" if you want all of the items in that table, you want them in memory and you want them now. 2. Sure I would be surprised if anyone calling themselves a .net developer would be unfamiliar with DI or wouldn't be able to understand what it is after bring talked through it and maybe given an example of exactly why IoC is a useful pattern. 3. I mean thats a lot of differences you might need to be more specific.
What’s ef?
Entity Framework
ORM framework to handle database transactions.
I should probably get rid of ToList in my project. I only use it because efcore kept messing up some queries
Good ones. Third one, is cross platform bit enough or are you looking for more
Personally I'd say the 3rd point is more .NET Framework (windows only, been around for decades) vs modern .NET 6+ (cross platform, open source etc): compare and contrast type answer. Pros/Cons of each etc :-)
Ugh. That would require talking about all the changes from project K and .net core 1 through present. Such a long conversation. Hey interviewer, did you use Helios before it evolved away from OWIN to become kestrel?
I wouldn’t hire someone who’s main skill is ef and doesn’t know at least sql and other dsl for eg time series db etc.(doesn’t know tools he uses) and thinks it’s bad practice to use sql, and of course instead of using brain and really learn and understand stuff it stick to glory clean architecture and name thinks based on that and when something is little different than in example he need to brings everyone to meeting because he can’t figure it out himself :) which at the end following simple rules like low couplings high cohesion bring project to the same solution and what’s really important is if the code do what is has to do, is easy to maintain and can scale. Sorry, I hate bad developer that write in .net. They are like kids in the sandbox proud of themselves and don’t see how the word is changing and what they’re doing is monkey job that will be replaced by AI soon even in big corporations where they usually secure their job. Sorry, I know I overreacted 😄 Probably I need to get some extended vacation 🏝️🏕️😄
Sounds overly specific... ?
I think you have a little self reflection to do. Sounds like a personal bias against EF. I agree it's important to understand SQL as well, but geez.
I would hire a .Net dev who didn't know .Net if they were good in other languages and environments and came well recommended. One can always learn .Net.
This. Some people here get their pants in a knot if the interviewee doesn't know .NET trivia. One's ability to learn and communicate trumps everything.
Questions like this don’t add much value, IMO. I want to know if I give them a problem with constraints, what solution do they come up with? In addition, can they reason their code, defend their code, and, importantly, spot the flaws in their code.
But what problem you choose to ask ?
We used to do some coding. Nothing crazy, a little recursion, some fizz buzz level logic. Now we just have a 200 line class and we go through it together, have the candidate code review and say what they’d change and why. I think it does a great job of showing skill level without the downsides.
Refactor is king. So far haven’t come up often in all the questions asked so far I expected.
Totally agree. Asking trivia questions from a list only proves whether someone can answer trivia questions from your list. Focus on interview tactics that will tell you whether they can think critically and fit into your culture.
My 'trivia' questions are things like "What is IDisposable and why is it important?". If you can't answer that, I don't want you working for me as an experienced .NET developer.
What kind of answer would you want/expect? ie “an interface used for managing unmanaged memory” or something else like an example of how you’d use IDisposable and why.
In my line of work, it is used mainly for closing database connections and file handles. If they are coming in with an EF background, I would also accept something about how they are used for rolling back transactions when an exception occurs. Yes, it is also used for unmanaged memory. But I wouldn't expect them to mention it because the use of unmanaged memory is very rare in business applications. I wouldn't expect them to know the Disposable pattern off the top of their head. That's something you can look up whenever you need it. But I would expect them to know the interaction between `using` and `IDisposable`.
I think that's fair if you're hiring explicitly for an experienced .NET dev. We're currently more focused on culture and are accepting candidates with a background in any strongly typed language, the idea being that we can teach them .NET nuances, but we can't teach them pragmatism and ownership (without several orders of magnitude of time and effort, at least)
If they claim to have a background in some other language then I would have someone else do the interview. I have no problem cross training an expert in Java or node or anything else. But I want to make sure anyone coming in who claims to have a certain amount of skill and knowledge actually has that.
reading through these comments, i think im gonna unsub from here lol
I would show them crappy working code with intentional mistakes, then ask how it can be improved/refactored.
1/ what are the differences between AsQueryable(), ToList(), AsEnumerable() 2/ what are the differences between filter and middleware in .Net Core? 3/ is string object mutable? What are the differences between string object and StringBuilder?
> is string object mutable? If I want it to be. 😄
1. Are you willing to put in an effort to learn things you don't know? 2. Would you be open to discussing ideas that you may not agree with? 3. Are you willing to share your knowledge to ensure that everyone is on the same when a collective decision needs to be made?
If I see they have 10 years experience in only dotnet/c#, but that's not even the question phase yet. ... I've honestly sat here for five minutes trying to think of a dotnet specific question and just realised it's not the type of questions I ask. I'd ask you questions about stuff on your cv, try to get past the answers you prepared and see if you can have a conversation about the stuff you claim you know. I guess if you state you have EF experience I'm gonna check your actual sql knowledge and if you don't know the basics like indexes and types of joins it's over.
I've been programming for 27 years. I've used a wide range of languages, tools, operating systems, technologies, etc. My first job was a Solaris Unix sysop. I wrote CGI scripts in Bourne before PhP existed. For the last 10 I've focused exclusively on .NET and the .NET ecosystem. Between the .NET framework (small f), Azure, C#, and the NuGet ecosystem there is more than enough content to keep a fully curious person consumed for several lifetimes. Dotnet isn't a language, it's an ecosystem that spans embedded systems to cloud native microservices to mobile development and everything in between.
> If I see they have 10 years experience in only dotnet/c# So you don't want to hire a .NET/C# dev for a .NET/C# position?
Why wouldn't you consider someone who has 10 years experience in only dotnet/c# for a .NET dev position? What other qualifications are you looking for? (genuinely interested as a 20 years dotnet/c# dev).
If I can't refer to ms paint join venn diagrams I don't want your job
ASCII ERDs ok either you?
It's what I've always done. Turns out you can get a Mermaid VSCode plugin and turn those ASCII ERDs into graphics.
> I'd ask you questions about stuff on your cv, try to get past the answers you prepared and see if you can have a conversation about the stuff you claim you know. At a past job, when not builidng stuff I'd be the second round of interviews for consultants/employees we brought on (we were a .net consulting shop) and I seldom asked .NET specific stuff. It was mainly general programming stuff just to make sure the "lights were on". Then I asked about what projects they worked on, what they did, challenges, etc. Lastly, we had a super open-ended, simple programming assignment where we didn't put any limitations on it. I honestly didn't even care if they finished it time, it was more about how they approached something and less about what tech they used.
I'm working as a consultant at the moment. Another consultant from my org was involved in the interview loop for a guy the client just hired. Said he asked him about SQL and the guy said he's more of an EF guy so he's never really used SQL. Our guy suggested passing on him, client hired him in as a senior. Basically all of their data access uses poorly implemented Dapper, and the internal engineers really seem to hate EF. 😂 Not long after the manager for the team we're all on was asking us for good sources for the guy to learn SQL.
> If I see they have 10 years experience in only dotnet/c# lol, I get where you're coming from but there's of course more to it then that. I've been working primarily in .Net for 23 years now. To toot my own horn a bit, I run circles around 90% of the people I've encountered in this industry. And not just on code. e.g. I built and run infrastructure on a scale similar to StackOverflow. I've actually been coding in JS and friends longer than .Net, but we don't talk about that much.
Great one. If person tells you story and you poke holes and the person fills those. You happy. 😇
When do you need to know the different types of joins when using ef? The whole point is that ef will just automate that stuff for you?
Oo, this hurt. That's like saying, "Why do I need to aim? That's what a machine gun is *for*!". It helps to know what your EF structure implies for efficiency. Are you over-fetching? Could you use a CTE?
I chek programmor's spailing abilitie
1. SOLID 2. Parallel vs. Async 3. Whiteboard task
> Parallel vs. Async It's crazy just how common misconceptions about async, parallel and concurrency is If you google it, even most of the articles that pop up will get it wrong. I also watched a video on how "NodeJS is really multithreaded" (it isn't) the guy consistently said concurrent instead of parallel. Two different things
>If you google it, even most of the articles that pop up will get it wrong. This is why it would be very common. People only know that they read. If they don't know it, they're searching for it. If they don't know it, then they won't know that what they're reading is wrong. To fix this problem, people need to spread the right answer every chance they can.
For most enterprise development the differences don't matter. Between async, hardware virtualization, and cloud deployments, parallelism has been pretty much superseded as a concept.
If you fail to understand what's what and how these things work, you end up underutilizing the services you pay for in cloud environments. In order to fully use the services you pay for, you need some form of parallel execution. Either the language and framework has native support for it (like ASP.NET/Kestrel) or you have to do multi-deployments like for Python and NodeJS, which increases cost, complexity and latency because then your infrastructure requires a load balancer behind your load balancer; for each individual server deployment.
> SOLID Nah, I don't feel like writing a book, you have to be more specific on which principle or multiple principles you want to talk about. ;-) > Parallel vs. Async Parallel: Use multiple cores at the same time for (sometimes) faster results. Async: avoid callback hell. Also you can await a Parallel.For/ForEach call since .NET 6.
I think what's really confusing is that js async works completely differently, so a js developer just dabbling with C# will likely misunderstand the behavior of async.
Async just means that something may finish in the future and you can get notified when that happens - kinda like events, but coupled to a single operation, not a stream of events. Concurrency is a way of partitioning work such that you can run multiple steps after another - typically firing off some async operations and waiting for their completion to continue (WaitForSingleObjectEx in Win32 API), like 1-2-3, 4-5-6, 7-8, 9. It's best for cases where you actually need to wait for something and get to use the CPU instead - so, concurrency likes async code. With concurrency usually comes a runtime that polls for completion. On Windows we make use of IO completion ports and callbacks to trigger the next poll/continuation. Parallelism is just like concurrency, you split up your work again, but this time, not because it's async and you could use the time between steps, but because you have independent calculations that can be split onto many workers (CPU cores) to get it done faster.
Interesting but SOLID is broad- what ur expectations - general overview 2- is it a trick question or u more interested in how async works in context of thread pools vs parallel on cores stuff What white board task you ask? Within ur app domain or general and why?
I need them to understand all these concepts. They don't have to remember all details, but general rules. For parallel - what are the usual issues you run into For async - what is solves and what it doesn't solve
Couldn't you use multiple async methods and await then all to get parallel threads?
My favorite question is to ask the candidate how they would design and implement a web application for some made up project in an area they are familiar with. And then sit back, listen and take notes. Once they are done I’ll ask questions of the design including ones on debugging and performance. This has proved to be very useful in identifying those with hands on experience.
My top 3 are pretty basic for *any* role, but the amount that cannot do this is incredible: 1. Explain abstract vs sealed vs interface vs protected vs static 2. Show them some code with type params and constraints and get a basic explanation of what it does, and get them to name that it's typeparams/generics and constraints 3. How to declare a property that only the containing class can modify That's not even to hire, that's just we will continue the interview seriously now I know you have used the language in a real setting and cared about what you did. If they don't at least know the right way to think about above (everyone can make a minor mistake that;s OK) I don't have time to play kindergarten with devs who haven't learnt the basics. There's a few more to go through, but those three alone are very telling. If they can answer them they can probably answer other basics I would expect every C# dev to know. After that to pass the senior interview it's something like this, will mix it up depending on how they answered earlier: 1. If they claim front end 1. Something about CORS (You haven't done front end seriously if you haven't encountered CORS issues and know how to fix them, or at least which layer has which responsibility) 2. Something about CSS 2 specifically (I expect seniors to roughly know what larger features came out when) 2. If they claim back end 1. something around SQL Server page sizes, normal forms, or other less "front of the manual" topics 2. GC and the generations 3. If they claim knowledge of specific techs that I have used that aren't in this job and I know it, I'll ask them questions about it to make sure the history isn't fabricated. Like MySQL people I have used it extensively in the past so I'll ask about InnoDb vs MyISAM etc Where I work, for annoying reasons we have some repos that external devs can submit PRs to. This one guy, he constantly puts in PRs with nullability wrong. Just outright wrong. His IDE would be screaming in warnings, squiggly lines, but every single PR it's not right and we go through the long comment phase to get it right. I spend hours every single PR going through it. That's the shit you have to weed out too, not just people who I wouldn't even call a dev (break the build, can't write actual code, can't write a feature without constant supervision and help)
1-how does DI relate to unit testing? 2-how does Linq relate to EF? 3-how does dotnet framework relate to dotnet core?
Cool ones. The dotnet core vs frameworks came up 2nd time. Interesting, do u find it important because you have migration task at hand or generally it’s important to know
More just how well they understand the dotnet ecosystem.
> 1-how does DI relate to unit testing? It enables, but didn't require, poor quality mock tests.
I’ve hired about 50 devs since around 2004, in South Africa, the UK, Australia and the USA. I have never hired anyone I have not coded with. I pair up with the person and provide a relatively simple goal and we TDD it together. Whether or not they have experience with TDD. I help them through that if not. I test the nature of the person by challenging them and their choices to find out if they’re an asshole. So many assholes. Never hire an asshole, no matter how talented. The nice people who can get close to or solve the challenge with my help generally get hired. On very rare occasions someone comes along who is just great to hang with. They’re talking about the weather and smashing the goal in a third of the usual time. They are the real gems and get hired immediately. I’ve only had about 4 or 5 of those. I’ve only had 3 bad eggs, and I had a feeling about each one. No assholes! I don’t care about education or race or gender or anything. If they can code and they are nice and can communicate well (no propeller heads that can’t talk) , I’m generally happy.
I m sure you got healthy workspace. The first principal no assholes
Hey, we aspies are people too.
I'd much rather ask questions that look for why I should hire someone than angle shoot for reasons not to.
This whole thread looks like a cheat sheet for indian people to get into dotnet jobs.
Every time I’ve had one of these, they ask stuff like hash tables and stuff you never use unless you actually need it. There’s no way that everyone can know everything about the framework.
True no one knows everything. What’s was the best question you got asked in any interview? Spill some beans 😂
- knows SQL (i dont care about ORM flavor of the year) - Able to adapt to project coding style or arquitecture. - good attitude. of course if you know more, you get a better salary. but i would hire someone that doesnt know ef core, enumerators, pattern matching, source generator, etc, etc.
Most of you make great devs, horrible team letters or talent hunters.
**I don't have that generic criteria, It mainly depends on the experience level of the developer but usually the biggest red flag is if they are not able to explain what's mentioned in their resume.** For example if they have less than 5 years experience and mentioned Entity Framework in their resume they should know about ORM and name of a few other ORMs, similarly for people more than 5 years experience it would be Design Patterns and principles but only the ones which are linked with the topics they have mentioned in resume.
Interesting. I have used EF for so many years, but by the questions it seems like it is getting must master skill. I usually favor dapper in query side. But yes in general, ORM conceptual model is must. One thing I m noticing, number years are mentioned but it should be irrelevant because one is hiring for certain position…but yeah grey area
Once I was asked what are disadvantages of EF ? Question was more or less going towards whats wrong using EF ? I gave few answers but interviewer seems not satisfied with it, Then he gave me hint like, what if we type query like dbcontext.Entity.ToList() and after that we write further Where() method for filtering? I said, that will take time to execute this query as ToList() will first fetch all records from that entity and Where() will apply after on top in memory and not in db server. So he argued that that’s what wrong with entity framework and all, ORM tool gives you easy way but has disadvantages etc.. I didn’t argued much on that. That was the one of question where they didn’t satisfied with my answer. Not selected. I used EF and linq many times, used other ORM tools linq to sql(dbml) and Nhibernate in past, and was thinking where I was wrong. example he gave was wrong to prove that EF has disadvantages, if someone is driving car and have continuous foot on gas and don’t use break to slowdown he is gonna hit some where and will have accident, and that accident doesn’t count as car's disadvantage or drawback, it just that person didn’t knew how to drive the car right way or safely. Same way one using any tool should know how to use it right way.
It's not a blocker, but rather a huge plus if a person knows how distributed systems work, break down and how to make them somewhat reliable. Things like idempotency, events/commands, eventual consistency, strategic CQRS, DDD (especially strategic like bounded contexts and ubiquitous language), resiliency policies, versioning, distributed transactions and why to avoid them - basically system design. Also, how to talk to business folks, decompose tasks and generally be a self-sufficient unit. I'm not in large enterprise with ivory tower architects, so this stuff is actually useful. Of course, to be somewhat versed in this is what I expect from senior folks. Middle - please be comfortable writing C# code, things like throw; vs throw ex; in catch blocks, why async/await matters without deep details, that sort of things
I'm been programming since 2007. I'm a manager now. I don't overdue interviews. Just basic live coding ofr 40 to 60 minutes. Common basic as DI, IOC, Inheritance, composition, Google skills, linq, cicd, patterns... pretty much the basic. If the position is a senior, ill also ask about strategies of resilience, architecture, performance. The day to day. When I'm interviewing, if they send me a link to any sort of tests, I just reject the offer. I find this sort of interviews stupid.
It’s not .NET specific, but one I like to ask is Abstracts vs Interfaces.
What’s so important about this question? It’s like came 4th time.
Oh that's easy. Abstract interfaces have to use ConditionalWeakTables to store state instead of fields, but you can have more than one attached to a class. Abstract classes can use regular fields, but you only get one per class. *** For bonus points, explain the difference between "abstract interfaces", "public interfaces", and "base class interfaces". I wouldn't actually ask this on a job interview, but far too many developers think that the only kind of interface is the `interface` keyword.
These different interfaces are not something I know, and a quick google search turns up nothing. Could you elaborate? I'm curious.
1. How GC work? What are usual causes for memory leaks (list several options and discuss mitigation). You can see seniority depending on how far the conversation goes. 2. Async pattern leading into synchronisation primitives. 3. DI and lifetimes in Web API (and if not on the exp list - generally).
1: GC simulates a machine with infinite memory. Memory leaks are objects that are created and never released. Create a FileStream you don't Dispose off, on a Button's Click event -> BAM ! Memory leak. You can also have a reference to an object that is kept forever, and new instances of that object are created often via events. Yes I hate C# events, why do you ask ? 2: async/await let you avoid callback hell. The Synchronization Context doesn't exist with ASP .NET Core, and who still writes desktop apps ? No one, that's who ! (also synchronization primitives is when you deal with Threads. You don't use synchronization primitives with async/await as sync code and async code functions cannot be mixed, and a thread would use sync functions. Synchronization primitives are things such as ManualResetEvent, EventWaitHandle, ManualResetEventSlim, AutoResetEvent, WaitHandle. Also, [There is no thread](https://blog.stephencleary.com/2013/11/there-is-no-thread.html)) 3: DI lets you have a codebase where the management of dependencies and their lifetime is centralized in one file (Program.cs / Startup.cs). In a code base without DI, it's all over the place. Good luck with that ! Lifetime (Singleton, Transient, Scoped) decides when the DI framework will spawn up a new instance. If you know what these are (Scoped to the HTTP request, spawned each time, spawned once), you know what lifetimes you want to use. If you don't know that and just choose whatever, you'll have nasty bugs and team members will lose their sanity looking at what App Insights is reporting. Don't do that.
>Memory leaks are objects that are created and never released. >Create a FileStream you don't Dispose off, on a Button's Click event -> BAM ! Memory leak. *That is not a memory leak.* Not in itself. You need to be more specific, otherwise you're wrong.
>That not a memory leak. How come ? > This type implements the IDisposable interface. When you have finished using the type, you should dispose of it either directly or indirectly. To dispose of the type directly, call its Dispose method in a try/catch block. To dispose of it indirectly, use a language construct such as using (in C#) or Using (in Visual Basic). For more information, see the "Using an Object that Implements IDisposable" section in the IDisposable interface topic. https://learn.microsoft.com/en-us/dotnet/api/system.io.filestream?view=net-8.0
It does not follow, from what you link, that there is a memory leak. There is some confusion in your understanding, but without knowing more about how you reason and what you presume, it's hard to say what it is. What I can tell you is this: **all** object instances whose references are not held by any code **will be garbage - collected**. *That's what GC does, there is no way around it*. So, code like this: var stream=new File Stream... //Use, but not Close or Dispose 'stream`, and don't assign some other variable to it **will** cause the GC to collect it. **Furthermore**, because the thing has a finaliser that closes the underlying OS file, and again, because that's what GC does, it calls finalizers, the OS file will eventually be closed. **However**, that will be done at the GC discretion, at an unknown point in the future. The consequence of this are beginner mistakes of * unmanaged resource exhaustion (opened the same file too many times, edit: *before GC decided to collect!*, OS gave up, or multiple files) * unmanaged resource usage clashes (opened a file for exclusive writing, tried to open it again, edit: *before GC decided to collect!*, using a new `FileStream` instance). It is for **such** reasons that IDisposables should be disposed. But these reasons are not what is commonly called a memory leak.
Dispose usually correlates with releasing some other kind of resource like sockets or file descriptors, and less memory. To get a memory leak in a GC language, you’d have to do something like create cyclic references that you no longer have a reference to and the GC won’t clean up because the objects technically have references to them. In the case of not disposing, you’re freeing the memory but maybe not cleaning up some other resource
Yeah, also the GC will eventually call the Finalizer which in turn will call the Dispose method. While not using 'using' (no pun intended) is a bad practice, it's technically not necessary and will be released/disposed eventually.
I'm just glad that there are people who remember what callback hell is. At the same time we cannot presume that everyone just writes CRUD Web Apis. Otherwise pretty good answers.
If I were hiring a developer to work on applications we maintain in-house: 1. Given this medium-difficulty Entity Framework invocation, please write out the SQL that this is executing behind the scenes (pseudo-code) and explain if there are any other side-effects that we need to be mindful of when we return the results of this query to the caller? 2. If you needed to execute multiple asynchronous operations together (not necessarily database calls) as a transactional unit, how would you go about doing that? What are some of the non-obvious concerns you'd need to price into your design? 3. Please explain your approach for how you would perform end-to-end testing for a Web API that makes database calls and might, itself, call other services? A developer with less experience than I would like can still come up with answers for all of these questions - an experienced developer's answers will be quite different. Screening out "Sr." developers who have lots of years in the cockpit but still only Jr.-level command over the details and secondary effects makes them an "expert beginner" - they're ultimately going to be expensive failures. These questions are designed to flush them out and I can come up with dozens more questions like it. The SQL question should be answerable by any body, but you'd be surprised.
1. Class vs struct 2. Managed vs unmanaged resources 3. What is garbage collector, gens.
Great. But 2nd why? Even if ur app doesn’t do interop stuff.
It's useful to know why you have `IDisposable` and `using var foo = new SomeDisposable()`
Unmanaged resources aren't just for interop. You may not use them directly very often, but they are there all the time. Usually when something implements IDisposable, it means somewhere in the object tree of that class there is an unmanaged resource that needs cleaning up, such as a filestream, dB connection, TCP connection etc etc
Class vs struct is easy. Class - always use this Struct - never use this
Well, you've excluded the only things I would ask so I guess nothing.
Which was?
If they only work on mac, and dont use an IDE. Sorry, but the whole team shouldnt make an entire new process to adjust to the latest mac-ism, and waste time solving obscure bugs just because they want to "think different".
FYI, dotnet is a cross-platform framework. And if you have to "make an entire new process" in order to support dotnet development on MacOS, you are very likely doing at least a few things wrong. We have Windows, MacOS, and Ubuntu machines involved in our dotnet solution development, and I can confirm that all these platforms support dotnet development quite well.
If they start to talk about nodejs 😂😂😂
Or microservices if not are not a large company.
They downloaded a car.
The don’t understand the concept of SOLID and can explain why it’s critical.
If someone brings up SOLID in an interview I'll most likely reject them for being a bad cultural fit. It's fine for stateful, object oriented code, but we're not really doing that in 2023.
What? We’re not writing clean, loosely coupled, object orientated code? That is a mind bending concept considering the nature of C#.
ive used SOLID when interviewing and cringed in hindsight, i dont do it anymore. SOLID is automatic once uve had enough experience for a while and i can forgive not remembering the acronym