Sindhai Kathiravan

My name is. I'm a MSC computer science postgraduate. I've been in the software development industry for nearly 15 years. My career has involved working on dot net development using SQL Server. I've worked with various Microsoft related technologies, including Windows applications, web applications, services, and APIs. I've developed a few SSIS package jobs and SSRS reports. I've designed and worked on various development and migration projects, including migrating from legacy applications to the latest technology and migrating from ASP dot NET applications to MVC applications, rewriting some application UIs without affecting business logic. We've developed Windows applications to help stakeholders understand requirements, converting business requirements into application development, using UML and diagrams. I've developed an end-to-end ERP application. I've worked in various domains, including banking, healthcare, insurance brokerage, telecom networks like Ericsson, air services, financials, hotels, and print media for Pearson publications. Throughout my career, I've designed subtle applications using Windows, web applications, and API services. I've consumed and exposed services. We've worked with all Microsoft technologies.

There was some incident when we were deploying work from on-prem to cloud environment. There was an unexpected issue at the time of cloud migrations. We had done a couple of format deployments and documented all the stuff. Somehow it was missed on the configuration setting, and I took that responsibility and worked through that with the help of the CCO IT network team and the third-party team. So that was the recent time there was a setback, we used to do.

What are some best practices you follow in developing a dot net particularly for other applications? Best practices completely implement the OOPS concept and solid principles, and we need a clear definition, clear segregation between the classes and create areas for each class, and all that stuff, as to decide whether it needs Windows authentication or single sign-on or forms authentication. It should be a very compatible, lightweight component that works on all kinds of browsers on the computer. We have various browsers from Edge to Chrome, Firefox, and Opera. We should check our browser compatibility and the content we are displaying on the screen. It should be so secure and easy to download. So all client-side and server-side configurations should be clear. Let's define what components can be exposed, what configuration settings should be restricted to data users, and browser compatibility and user experience, how it should be used when it's a public-accessible portal. We're challenged to ensure that persons can also access that application without any issues. Browser compatibility is key. We prefer responsible designs instead of using heavy-weight images and large volumes of data. We always prefer lightweight page designs with very limited and soothing color combinations on the UI. Easy access user experience should be very flexible, and the color should not affect all screens. And they should be easy to deploy, easy to clarify whether it's coming to scalable. It should be easily expandable into the next level, and we're adding new features. Design principles and solid principles can be implemented for good maintainability and authentication. We can maintain a form level. If it's an in-house application, we can go for single sign-on AD authentication, or Windows Direct authentication. Windows authentication is against the Active Directory authentications.

So the API and the asset compliance, can you describe how you have used them in building a web page? So I have used the web APIs to create web API views to go create a C# application within my Visual Studio. The web API controller was created, and inside the controller, put post, delete, get methods with the HTTP verbs. We can implement that. We can implement token-based authentication to access the web API. From the controller, we define all the input parameters and validate the input parameters. They are not null and in the expected format. If failed, we throw back an invalid input bad request exception to the consumer who consumes the web service. Everything works fine to send back a valid request to them. Internally, we handle exceptions and throw back all the earlier invalid exceptions. For invalid bad requests, it can be thrown there. If any internal exceptions, we can generate a complete error code and error message dictionary. We can publish to the consumer so they can see bad requests or any validation errors or application errors with one error message, and we can throw with that error and a description combination dictionary to that fault contract, I mean, exception. Token-based authentication is good to have, and authentication keys and the auth code can be shared internally. After receiving the request, we can build the body of that and process the business logic. If any data access, we read the data access and get the data. We make it presentable. It can be in some format. We can send back a string or a JSON string with the result of the HTTP response back to the consumer.

I took the initiative to solve a problem that wasn't necessarily my responsibility. The situation was when I was leading a team and facilitating them. Often, they would start with technical help, but technically, they wouldn't move forward, and I'll elaborate on that later. I would sit with them and provide technical solutions. This involved reading a file from the UI, uploading it to the server, handling a huge volume of data, and sending it back to the UI or binding that volume to the UI. I extended my support to the support team, which is something that happens frequently. I used to work with them, and I was happy to do so. It gave me pleasure to share a problem and provide a solution. It wasn't just about sharing the solution; it was also an opportunity for me to gain knowledge. Having that kind of behavior is always good. I used to do this all the time to help the team. This wasn't the only recent time it happened. Throughout my career, I've often worked with my fellow subordinates, my team members, to help them technically with their difficulties, and we were able to come across the situation together.

Can you explain what delegates and the events are in C#? And how you have used them in your project? In what situation would you choose to use an interface over an abstract class in C#? Explain how garbage collection works in C# and what impact it has on your development. Delegates and events. Delegates are a reference to a function. Again, no need to directly call the function. By delegating, we can call that reference instead of directly accessing the functions. Even so, we can trigger from a code behind, when there's a customer object, some multiple users are accessing that object. When the object, the customer object, is modified by a different user, it will reflect on another user's screen. So we can write this event on the customer status change by other users. So when it gets impacted, it will trigger the event, and it will reflect on another user's screen. By the way, you can implement events. This is one, for example, recently used. Comparatively, interface and abstract class, in a very high level, both serve the same purpose, but it's not actual. When we're going for an interface, we have to implement all its functions, properties, in the interface. But for an abstract class, we don't need to. It's a literal meaning, it's abstract. So the class and its functions can be used. The functions are from this class function. I mean, abstract class functions can be consumed if we need, if we need to, no need to be. But, we need to implement the same kind of complete structure or complete, same kind of implementation we need for all the classes, then we should go for an interface. All the functions in that office need to implement on the where we are implementing for the class. Garbage collector, when the objects are abandoned, not handled programmatically, it will clear all the objects. It will, that's generation 1, generation 2, generation 3. So, least used objects first, it will come into load, and it will clear that object and clear the memory. Then 2nd gen next generation next generation, it will go like this. So, the garbage collector is used to clean the unused objects. By using the using keyword and C# object instantiation, it will fix by default.

When would you choose to abstract functionality into reusable piece of code? Can you explain your approach to deciding when and how to abstract a code? When designing a car, we use a car with four wheelers and gears, and an all internal combustion engine with gears, wheels, and 4 wheels, and the gears, 1, 2, 3, 4, 5. And, we have an automatic model also. When we design a car with abstraction, it has 4 wheels, gears, and an automatic feature. When the car model and car one implement the abstract class, we don't need to get all the functions. We can use only the gears and the wheelers. When we are implementing an automatic car, we don't need to implement the gear function. We can implement only the automatic function and the wheelers functions. So, we can decide based on our requirement when we are consuming or using an abstract class. The basic abstract class name is a car. The real class name is the automatic car and the manual car. When we have a manual car, it implements the abstract class car. We can use only the gears and the wheel gears and the wheels. When we are implementing an automatic car, we can use the automatic drive and wheels. So, wheels are mandatory for both the models, but gear or manual automatic gear, it is based on our requirement. We can decide that this is a very simple and neat example for choosing abstract functionality for reusable pieces.

Between views, functions, and stored procedures. So views in the database, it is a clear select statement only. Views, we cannot have other operations like insert, update, or delete. So it cannot be modified or deleted data for use is used to combine complex kinds of joins. No need to use an inline query. When we are using a select statement, every time it will create an execution plan, it will take more memory. But when we create a view, it will create a predefined precompiled execution plan, complex joins. So it will give performance improvement. This saves us from SQL injections from applications when we are implementing. So functions, it is a value that is returned. It can be a scalar or any record, table type records. It cannot be used alone. It can be used in the select statement or to calculate data. Stored procedures, we can use any number of any kind of functions, the insert, update, delete, all kinds of database manipulations. You can read, delete, update that stored procedure. Queries inside the stored procedure, it will return any record set or it will return any scalar or it can be wide. It is also a predefined precompiled SQL statement. It has input parameters and output parameters. We can pass that by inside the stored procedure, we can call another stored procedure, nested stored procedures. It is a precompiled stored procedure, complex joins, or multiple operations we can do. Multiple operations on multiple tables we can do inside the stored procedure by implementing transactions. So rollback, commit, begin transaction, rollback, commit operations. We can implement try catch for exception handling. We can add conditional executions, if flow, If conditions, everything can be done in short procedures.

Accuracy and the reliability of your data analysis are required before presenting your findings. If the requirement includes any calculations, you can opt for manual calculation or programmatic calculations. For account data count and verifying the data, you should have some key. So, you have to compare the data, correct the result, and expect the actual result that can be manually verified. For small accounts, you can go for validations. If it's millions of records, you can validate and manually, then go for a programmatically automated approach. The reliability of your data analysis before presenting your findings requires that you have valid data, then you can validate the expected result that you might derive when writing procedure or function or starting with expected result test cases. After implementing unit testing, you can find your actual result to be very well. The generator result against the expected result and actual result can be validated, and you can come to know that it is valid, the accuracy, and the data label.