Tu entrevista tecnica, en ingles

I've been leading the technical side of a small team, and I've learned a lot, but I want to work at a bigger scale and with people I can learn from. I'm looking for a place where engineering standards are already strong.

I tend to go too deep into a problem before asking for help. I've been fixing that with a simple rule: if I'm stuck for more than an hour, I bring it to the team. It made me faster, and honestly it made the team faster too.

A teammate wanted to ship a feature that our data could not really support. Instead of arguing, I pulled the numbers and showed what we could and could not prove. We ended up shipping a smaller version that was honest. I've learned that data ends discussions faster than opinions.

I once shipped a change that looked fine locally and broke a report in production. I rolled it back within minutes, found the cause, and added a check so the same thing could not happen silently again. The lesson for me was that 'it works on my machine' is not verification.

I cut scope, not quality. I ask what the deadline really needs, ship that part properly, and I'm explicit about what is not included yet. In my last role we delivered a hundred percent of our milestones on time that way.

Still building, but with more architectural responsibility. I like being the person who can go from the database to the front end and keep the whole thing coherent.

dot NET Framework is the old one, Windows only. Modern dot NET, version five and up, is cross platform and open source. Today you would start a new project on dot NET eight.

It means a class does not create the things it depends on, it receives them. ASP dot NET Core has it built in: you register services in Program dot C S and the framework injects them into the constructor. There are three lifetimes: singleton, one for the whole app; scoped, one per request; and transient, a new one every time. It makes the code testable, because you can pass a fake one in a test.

Language Integrated Query. It lets you query collections or a database with chained methods. It is the same idea as filter and map in JavaScript: Where instead of filter, Select instead of map.

Value types like int, bool and struct are copied by value. Reference types like class, string and arrays are passed by reference. It is the same distinction as primitives versus objects in JavaScript.

First I would look at the execution plan instead of guessing. Usually it is a missing index, a function applied on an indexed column, or a query pulling far more rows than it needs. I would fix that, then measure again. I do not optimize anything I have not measured.

Authentication is proving who you are. Authorization is what you are allowed to do once you are in. Logging in is authentication; being able to delete a record is authorization.

Resources as nouns, HTTP verbs for the actions, and status codes that mean what they say. I validate the input at the edge, I never trust the client, and I keep write operations idempotent where I can, so a retry does not create a duplicate.

Not in one step. You add the new column first, deploy code that can handle both shapes, backfill the data, and only then remove the old one. The order matters: if the migration and the code go out in the wrong order, the app breaks in production.

Tests for the logic, and real verification for everything else. I run the build, I check the actual output, and for anything user facing I open it and look at it. I have learned not to say something is done until I have seen it working.

An index makes reads faster by keeping a sorted structure the engine can jump into. It costs you on writes, because every insert has to update the index too. So on a table that is written constantly, too many indexes will slow you down.

With client side rendering the browser downloads JavaScript and builds the page. With server side rendering the server sends finished HTML, so the first paint is faster and search engines can read it. In Next J S I pick per page: marketing pages server side, dashboards client side.

I don't think one is better. Node is great for I O heavy services and for sharing types with a TypeScript front end. dot NET gives me a stronger type system, better tooling for large codebases, and it's usually what enterprise teams already run. In practice I choose the one the team can maintain.

It packages the app with its dependencies, so it runs the same on my machine and in production. It removes the 'it works on my machine' problem. Kubernetes is a different layer: it decides where those containers run and restarts them when they die.

Never in the repository. Environment variables or a secret manager, injected at deploy time. In Cloudflare I use secrets bound to the worker; in A W S, Secrets Manager or parameter store. And I rotate them if they're ever exposed, instead of hoping nobody saw it.

Unit tests for logic that has rules, integration tests for the paths that touch the database, and manual verification for anything visual. I don't chase a coverage number. I test what would actually hurt if it broke.

Retrieval Augmented Generation. Instead of asking a language model to remember facts, you search your own documents first, and you give the model only the relevant pieces as context. It's the difference between the model guessing and the model quoting your data. I built one at BIT512 over Oracle and PostgreSQL sources, with quality checks on the answers.

You ground it: give it the source text and tell it to answer only from that. You keep the retrieval quality high, because bad context gives bad answers. And you validate the output. In my own product the rule is simple: if a number can't be traced to real data, it doesn't get shown.

D N S resolves the domain to an I P, the browser opens a T C P connection and a T L S handshake, sends an HTTP request, the server responds with HTML, and the browser parses it and requests the CSS, the JavaScript and the images it needs to paint the page. Along the way there are caches at almost every step.

I start from evidence, not from a theory: logs, metrics, and the exact request that failed. I try to reproduce it with the same input. If I can't reproduce it, I add the missing observability first, because guessing in production is how you make it worse.

I look for correctness first, then for things that will hurt later: naming, error handling, and anything that hides a failure. I try to ask questions instead of giving orders. And I say what's good, not only what's wrong, because reviews that are only criticism make people defensive.