This month I'll be focusing (Or unfocusing, if you will) on a few things I've learned in my career that college didn't teach me. So without further ado:
Idempotency: Idempotency means that a process or action that is taken in your system will not repeatedly perform on subsequent executions until the first execution is finished. You know how your credit card won't charge you multiple times if you hammer the "Buy Now" button on Ebay after selecting the card you want to use? That's idempotency.
Multi Tenancy: This one relates to databases and means that your DB is segregated across several domains, and that accessing one domain only allows access to that domains data. My Human Resource Support System thesis poroject used multi-tenancy to segregate several customer accounts for each of their relevant systems, user accounts, etc, then only allowed access on a subdoomain basis. So microsoft.humanresourcesupportsystem.com could only access Microsoft's data, and facebook.humanresourcesupportsystem.com could only access Facebooks data, and neither system could access the other's data. It's not something you should immediately consider using if you're faced with a problem that it solves however (Such as having more than one customer: go you), as customers might feel very iffy about having their data stored in the same database as a competitor (Or just some other business/entity). It's still a neat concept.
URL vs URI: A URL is pretty self-explanatory. A URI is a URL with valuable information in the address (Such as personal details, etc).
Business Analyst: If you're working for a very small business (And sometimes this is still not the case) you might not have BA's. These people translate what specific technical business needs your customers have (We want X feature) to something that you can understand as a developer. In smaller businesses, you may have to figure out what the customer wants/needs by yourself. I say want/need, because BA's can also act as gatekeepers for when the customer wants something that cannot be done (Due to technical reasons, etc), should not be done ("This is a bad/awful idea because it will break everything or is completely unrealistic" and/or "We can already do this if you just use Y instead") or the customer doesn't understand what they actually want (And the BA can point them in the right direction).
Staff SE/Principle SE/Super duper Senior SE: These generally mean different things in different companies, but always translate to "higher than senior" in some way and tend to have more ownership of technical things specific to their company ("I am a staff SE and have authority to do everything, but am also held more responsible when things go wrong"). There's a bit of overlap between the higher engineers on this list, and the next (Architects may be treated as staff SE's, and vice versa. Sometimes you'll only see staff, sometimes only architects, sometimes both, sometimes neither!).
Software Architect/Designer: These folks make big technical decisions for companies and are a great technical (And often business) resource. If you're lucky you'll get a few chances to chat with them and will benefit greatly from it (You're new and want to know the best way to get to grips with codebase? Seriously, ask one of them). They tend to be heavily invested in the company, employed there a long time, know huge parts of the codebase and have a great grasp on domain knowledge!
Account Manager: I have only seen these in large multinationals with a lot of very wealthy customers. They manage relations, staffing and other resources for customers, but usually are not involved in other technical needs or business requirements. They do a lot of background stuff that you won't see as a developer.
Technical lead vs. Project lead: You report to your tech lead on your current tasks. Usually they'll pair program problems with you, advise you on how to deal with immediate issues (Current sprint problems, if you're running projects under SCRUM), etc. Project leads might have some contact with you depending on how small your team is and the project you're on. Generally you'll only talk to them in standups, if at all.
Best of luck!