Don't forget: They probably existed before you arrived, so don't pass judgment on any technology/code they are currently using. Ask if they have heard of "the alternative" when you discover something that isn't what you thought it should be (i.e. Using X DB instead of Y, Tool A instead of Tool B). If the company is progressive, they will already know about "the alternative" and it may be in their plans to change... it may not because "the alternative" is not "blank_" or sufficiently stable for their uses.
Always ensure your solutions match their requirements for uptime, stability, support and capability. Your answers may sound great from an academic perspective, but many academic answers are terrible solutions in the real world when you have 1 day to do something that you could have spent 3 weeks on while in school. (Maybe a side project opportunity to show off a bit??)
Be on the lookout for a quick shortcut that was taken because of a "fire"; notice how they solved the problem and Why. The why of everything is MUCH more important than the how. There are always 5 potential solutions to a problem, with 100 trade-offs between them. Knowing why the team chooses a certain solution can make you more immediately "useful" than having memorized 20 other technologies that may or may not really fit their codebase or solution matrix of today.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Don't forget: They probably existed before you arrived, so don't pass judgment on any technology/code they are currently using. Ask if they have heard of "the alternative" when you discover something that isn't what you thought it should be (i.e. Using X DB instead of Y, Tool A instead of Tool B). If the company is progressive, they will already know about "the alternative" and it may be in their plans to change... it may not because "the alternative" is not "blank_" or sufficiently stable for their uses.
Always ensure your solutions match their requirements for uptime, stability, support and capability. Your answers may sound great from an academic perspective, but many academic answers are terrible solutions in the real world when you have 1 day to do something that you could have spent 3 weeks on while in school. (Maybe a side project opportunity to show off a bit??)
Be on the lookout for a quick shortcut that was taken because of a "fire"; notice how they solved the problem and Why. The why of everything is MUCH more important than the how. There are always 5 potential solutions to a problem, with 100 trade-offs between them. Knowing why the team chooses a certain solution can make you more immediately "useful" than having memorized 20 other technologies that may or may not really fit their codebase or solution matrix of today.