Also, VMWare has A LOT of fat to trim. I've worked closely with teams and alumni of Broadcom/Avago, VMWare, CA Technologies, and Symantec, and honestly, the cuts Broadcom does are pretty reasonable.
This is probably what's going to happen. Companies like Broadcom and PANW want pretty high margins on their product lines, so they're pretty mercenary in getting it done.
If you got an offer letter, you should probably survive if you can justify your value over the next few months (in my experience w/ M&A)
Oh, VMware is the 2nd shortest job in my career, primarily for that reason.
I don't want to say much in a public forum, but my best lesson from working at VMware is how to sniff out an incompetent engineer early in a job interview: I just ask coding questions that a VMWare engineer would get wrong.
For example:
I have an engineer write some very basic manual SQL data mapping code. If the candidate really pushes back, or just can't figure it out, I move on.
I ask a question where the engineer should use an enum instead of a string. If the engineer uses an enum, I move on.
Also, a lot of their early management feel like one hit wonders in my experience working with them.
It reminds me of how PANW was before Arora joined and cleaned house, and Symantec/CA before Broadcom cleaned house.
And many of those one hits were ideas crafted and handed to them for implementation (still valuable and important), but left to distill ideas on their own? Not so much.
I’m confused by this. You’re saying you move on if the engineer uses an enum as you would expect?
Do people usually have the SQL language so well memorized that they can pull it out of their head on command? I swear to god I'm not the only engineer who regularly goes to the cheat sheet.
If you're hiring for a SQL developer I guess it makes sense, buit I use SQL about once every 6-12 months or so, so if you hit me with SQL queries on the spot I'll fail your interview for sure.
Honestly, I find interviews that revolve around memorizing and regurgitating some programing language syntax trivia a bit shit.
Wouldn't it be better testing for critical thinking and problem solving skills instead of shit people google anyway?
If I were interviewing for database/SQL work, I'd be personally probing around understanding of the relational data model, not specifics of SQL syntax. How would you model this table? What's a join? What's normalization? What's wrong, conceptually, with the following schema? etc
I think the key insight for you here is that there are many jobs where the only technical skill used is SQL. You probably should know this stuff like the back of your hand for such roles. Old, slow moving, large companies have many people doing this sort of work.
Contrast with a generic "developer" at some startup who uses SQL as only one part of much larger and more complex applications.
As a "developer" you have to deal with so much obscure syntax in your life (actual programming languages, shells, dockerfiles, kubernetes yaml, helm, god knows how many 3rd party APIs, ci/cd definitions, other rando DSLs...) that you won't be able to keep everything in working memory.
But I think that supports the GPs point. At big companies you are more specialized, which means if you get hired into the database dev team you better know SQL really well, cause the non-database devs won't even get access to it and instead depend on you.
I don't expect everyone to have everything memorized or get it right on the first try, but if you don't even know what questions to ask or what resources to confer with, I'm usually concerned if the candidate will be a good fit. The candidate can't be expected to instantly warp to the solution but they need to show they can begin to find the path.
- DDL: create, drop, alter, truncate
- DML: insert, update, delete, call, explain, lock
- TCL: commit, savepoint, rollback
- DQL: select
- DCL: grant, revoke
If you've used them before, you'll have a good enough intuition to understand what each does and when to bring them out of the toolbox. Some database engines have extended versions of these or other ways to achieve the same result, but the underlying concepts are the same.
From there, you should be able to create a basic SELECT statement, and understand the basic flags:
- FROM
- WHERE
- GROUP BY
- HAVING
- ORDER BY
- LIMIT
Then understand joins and how this is all just relational calculus/algebra with sets.
Honestly, I couldn't list these off the top of my head, but I know what each one does when I see them, and I'll instinctively reach for them when I'm writing SQL. But once you know all of this, you know 80% of the SQL you will ever need, and won't have to reach for an ORM. It only takes one weekend to grok SQL, but it will serve you for the rest of your career.
Can't agree on that. If I don't use a language or certain concepts I learned more than 6-12 months, I forget it. Groking something in one weekend that you won't immediately put to use then it gets immediately flushed by the garbage collector. At least for me.
It's like asking a chef to make a hamburger, and telling them how to turn on the grill and where the ingredients are. Either they can do it, or they can't; but you can learn a lot about them by watching them do it.
Abacus, slide rule, grid paper, mechanical pencil, or gtfo!
IT is data librarian work. I compute with raw materials of reality, not 1970s semantic babble. Software as an industry has a lot of fat to cut.
…The argument can work from various contexts. Not the flex you think it is.
The project I was on at VMware failed because the developers refused to learn how to use a database and just threw an ORM at it.
So I would write on the whiteboard a skeleton method that had a SQL query, explain a simple data reader API, and have them fill it in.
The good candidates got it fast, and then we'd discuss various error conditions and how to handle them.
The bad candidates would get stuck, whine that I didn't allow an ORM, or hallucinate that they could answer with an ORM: IE, the question did it's job.
Layoffs seem pretty bad at identifying the incompetent from the competent from my experience. It seems to cut on all front, you're not sure if you're left with the best or the worse ones, but you saved a lot of payroll cost either way.
Or if you try to handicap teams by understaffing them, even competent engineers will need to reduce the quality of their output. This is when fat is trimmed in a bad way, where instead of getting rid of low ROI venture/projects/services/products and focus on the important, you just tighten the budgets accross the board for example.