helix90

the video requires signing up for Yubikey spam. https://app.livestorm.co/yubico-y/securing-trusted-actions-a...

Listening to Yubikey and OnePassword talk about this, they actually say "One Person, One Device". Which really speaks to their failure to understand their users.

The common one I fought long ago was folks who always use regular expressions when what they want is a string match, or contains, or other string library function.

Can confirm. Got the same e-mail sent to my Sendgrid registered e-mail address. Fortunately I also got an e-mail from one of the apps I have that uses Sendgrid so I assumed it was phishing and logged in by hand to check.

If I were interviewing you for an Embedded position I would ask questions about how your skills with .NET and React applied to your embedded projects. I would review your github repo and ask about the embedded projects there and what lessons you learned, and how they were different than a .NET project.

Changing specialties is rough, but I have done it more than once. Embedded is a strange space, but you can break in.

My former CEO would tell you "if you depend on people changing their nature, your product is not likely to succeed".

I got Duct Tape Developer. No lie detected.

You should check out both Go and Rust as new languages that are excellent for back end services. If you want to explore a little more, also give Zig a try for a toy project.

USPTO says: https://www.copyright.gov/ai/

I ask hard questions to see how you handle them. One of the most important things you can say in a technical interview is "I don't know". You can't know everything, and how you handle running off the end of your knowledge says a lot.

This is a question I use when interviewing devs for writing REST API.

The answer is either way, and it depends on the tooling you are using. If you are relying on a client library that doesn't handle HTTP errors in the way you want, then you return a 200 - OK {"error": "bad request"}. If the client library does what you want, then returning a limited selection of 4xx errors is very useful for letting the client know what happened quickly and easily.

Personally, I default to using the HTTP error codes. But I know that some really large companies don't agree, and always return a 200 OK to any valid request.

for the programming part, I ask them to get the answer from the LLM and then code review the solution as part of the interview.

MySQL Redis