Hacker News Reader

Comment by gwbas1c | Hacker News Reader

> VMWare has A LOT of fat to trim

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.

View on HN

> I ask a question where the engineer should use an enum instead of a string. If the engineer uses an enum, I move on.

I’m confused by this. You’re saying you move on if the engineer uses an enum as you would expect?

You're not confused. As the OP indicated, he was once a VMWare engineer, so he gets his own questions wrong.

Takes one to know one. Checkmate.

Incompetent managers seem to love shorthand "competency" tests like this.

No I should have said string

>I have an engineer write some very basic manual SQL data mapping code.

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.

> 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.

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.

Ironically working at a big old company I wrote almost no SQL, because the database was DB2, so we had dedicated Data developers to write stored procedures in COBOL / SQL. While at a small shop and a more modern tech company I wrote tons of SQL.

Same, my best experiences with getting data out of DBs - in an earlier job where I had to work with many external customers directly - were the big ones, cause they always had dedicated Database dev teams that could prepare the data in a way that worked for me and the database. Contrast this with the small shops, which - if at all - had someone as a db admin (usually in addition to their normal job) and could only provide database access and "here, figure it out", which meant I had to write all the SQL myself.

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.

People doing whiteboard coding should not have to get the syntax 100% (or even 80%) correct. It should be enough to just show conceptual understanding of what kinds of syntactical elements and concepts are present in the language. When I trained for giving interviews @ Google, this was emphasized, at least. It's not about getting the syntax exactly right, it's about getting the algorithm right. Though obviously if someone is getting something fundamental wrong, it raises eyebrows.

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

When I give coding interviews I often jump in with "it doesn't compile because you forgot the semicolon at". The tools we use don't make it easy for me to fix such mistakes and it doesn't pay to waste their time to search out a mistake I (as an observer) already happened to know - I want to see their algorithm work so we can move on (or see how they debug why it isn't working yet depending on what phase we are in). I don't really care how long it takes you to find that missing semicolon - we all make that mistake once in a while and there isn't much to learn from it.

As with any language, developers who use SQL a lot do memorize it. Maybe not every bit of it but all the commonly used bits. I used to write SQL and PL/SQL every day at work and I got to the point where I rarely needed to consult the manual.

>As with any language, developers who use SQL a lot do memorize it.

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 you're not hiring a SQL developer I agree it doesn't make sense to ask them memory questions about SQL. But it does make sense to ask them memory questions about whatever it is they claim to know. A developer who has to google the basics is not going to be very good at problem solving.

Any time I've participated in a technical interview as an interviewer we've had the candidate have full access to a computer and web browser.

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.

Ideally, yes you should be able to understand and recall all of the basic commands:

- 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.

>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.

I have to use SQL like 1-3 times a month and can confirm that the syntactic inconsistencies of the language make me go to the cheat sheet regularly.

I am a SQL wizard and I have to lookup and experiment with the syntax every time I use it. Every engine handles it differently, which is a little maddening.

I provided the query, the skeleton of the function, and I explained the API of a simplified data reader.

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.

Incompetent engineers and fat to trim I feel are seperate issues.

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.

As an EE, when someone explains they need SQL, all the other hallucinated semantic handlebars to compute, I move on.

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.

If said candidate's whiteboard response doesn't use at least two main spurving bearings, culture fit comes into question.

You should really check out Agile if you want to understand why software is so messed up now. It’s been perverted to basically mean “rush out product features every two weeks that product managers think are interesting” in many places.

Unfortunately it sounds like you're filtering on things that can be easily taught.

That's kinda the point.

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.

I think the idea is that if they don't know something basic you can forget about the hard stuff.

I used to do that as well when I was still a SWE and then a PM. VMWare has good talent (when I first became a PM a long time ago, I was mentored by a very smart VMWare PM alum), but it also has a lot of empire building (when I first became a SWE a large portion of my management was VMWare EM alumni who weren't that impressive).

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.

> Also, a lot of their early management feel like one hit wonders in my experience working with them.

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.

Reply on news.ycombinator.com