Determining the Minimum Knowledge Base to Say You “Know It”

Posted by sketchcarellz@reddit | ExperiencedDevs | View on Reddit | 30 comments

I’m a senior software engineer and my wife is a talent intelligence lead. Among a lot of other things she does, she writes a lot of white papers and digs into talent intelligence data a lot, then summarizes that data into easily digestible emails for executives, directors, and managers to read.

She wants to up her technical skills, and data analysis/engineering seems to be the logical route for her line of work., I am probably going to help her start learning SQL and Python.

This got me thinking; what is the point to where she can tell someone she “knows” SQL? (same with Python) There is an insurmountable amount of knowledge associated with relational databases. If I met someone and they told me they “knew” SQL, and that meant they knew:

-basic select statement queries

-aggregate select queries

-primary and foreign key relationships

-basic understanding of the rest of the CRUD operations (insert into, update… where, delete from)

I wouldn’t argue that point. The above alone can be overwhelming for someone who doesn’t know anything about RDBMS’, but that is a good goal with a reasonable light at the end of the tunnel, especially for someone who is not focused on data engineering as their job.

I think that this concept is great and provides a benchmark for people to learn without feeling overwhelmed.

What is something you feel like you could talk about related to this, and what is your short list for someone to say they “know” something?

[-]

AdeptLilPotato@reddit

I think that there will always be people claiming to “know” different technologies or skill sets before they’d be truly, from an objective standpoint, “qualified” to say they know what they’re talking about.

Moving past that, I do think that it’s a subjective experience to identify when you “know” something, which can be measured generally pretty objectively from random people also in “the know” already.

The reason I haven’t become very specific in regards to SQL is because I don’t know enough SQL to say I know it, but I also am approaching this from a different skill’s perspective, which is partner dancing.

In my opinion, in order to identify that you know something (that is sufficiently complex), you need to be able to have experienced the expansion of your understanding of the amount of knowledge there is to learn in the subject.

Most people learn a thing, and they know so little, that they can easily claim to “know” the subject. I think it’s a pre-requisite to truly knowing a subject that a person can confidently say that they have learned enough to say they know a bit, and that they have learned enough to say that they also know nothing.

Connecting this to partner dancing, any objective, random person without dance experience, will look at my dancing, and can look at other average dancers, and would be able to easily say that I “know” what I’m doing.

And if you ask me, I can tell you I know enough that I can help some beginners get started, and yet I know so little, that there are so many things I don’t know that I don’t know still. For context, I’ve been going out to socials doing partner dancing weekly for nearly a decade.

The person worth knowing isn’t the one who can claim they “know” a subject. It’s the one who has been diving into the subject long enough to tell you they know generally how much there is to learn, and that they know little in the grand scheme of things.

TheOneTrueTrench@reddit

I "know" something as soon as I'm the go-to person when someone has a question.

jebucha@reddit

This is from a job hunting training that Jason Blanchard (Black Hills Information Security) gives:

3 levels of skills 1. Familiar with or knowledge of - taken a class, watched Youtube/LinkedIn training videos, etc 2. Proficient in - do this on a daily / regular basis 3. Expert in - I know it so well I could teach it to somebody else

ConsulIncitatus@reddit

The minimum knowledge required to say to someone that you know something is the amount of knowledge the person you're saying it to has on the subject.

CVisionIsMyJam@reddit

why don't you ask her? what would she need to know how to do to feel confident in saying she knows it? I assume she'd be telling people that in her circle, not yours.

sketchcarellz@reddit (OP)

“Why don’t you ask her?” Why would she know that? She is learning SQL. She doesn’t know what she doesn’t know. I went to school for accounting. If my professor asked me year 1 what it was that I needed to know, I would look at them like they were crazy. I didn’t even know the terms to describe what I didn’t know yet. This doesn’t make any sense.

This wasn’t a post about advice on what people specifically think it takes to “know” SQL. If you read my last paragraph you’ll see that I was just asking what is a topic, any topic (specifically typed “something”) that people feel like they could speak to and the minimum it would take to know that topic. I listed what I thought it would take to know SQL on a super basic level already.

This was just to open up a conversation and get general opinions in the spirit of conversation, that’s all.

ListenLady58@reddit

I usually say I know something if I successfully build something with it or integrate it. If I get stuck while building, I find some tutorials and start from scratch. Then once I build a small program, then I go back to my other project and start building more. If I get stuck, rinse and repeat.

matthra@reddit

For SQL, I'd say window functions are the final boss of basic sql. They require you to understand aggregation strategies, thus how to group, write subqueries, use qualify, etc.

After that you are in diminishing returns territory, and start picking up domain specific SQL skills like geo SQL, JSON, vector embeddings, platform specific optimizations, etc.

tutamean@reddit

What are window functions?

johnpeters42@reddit

I've used a couple of these without knowing the specific term, mostly rank() and dense_rank(). Will have to play with the others and see if I spot any use cases for our work.

Rank is probably the most common, that or row_num. After that is probably first_value, you use that to select one value when multiple are available, I use it mostly to replace select top 1 subqueries. Non data engineers might have different ones like I hear avg is quite common on the report writer side of the house.

JollyJoker3@reddit

TIL there are things called 'window functions'

cc81@reddit

You truly only know SQL after you have seen 500k rows affected when you expected 2. (You did not use transactions)

No, but seriously it depends on context for me. They should be able to get or insert the data they need from a database and not do anything too stupid.

DigmonsDrill@reddit

You have the standard graph of people learning things then feeling smart then learning more things then realizing how much they don't know then slowly climbing up the graph of knowing more things.

I've spent time on the postgresql-* mailing lists. Against any of those regulars, I don't know anything. Against anyone who isn't on that list, I know everything.

double-click@reddit

When you can perform the basic qualifications of the job ad.

flerchin@reddit

"Know" is basic level. That's why we typically talk about years of experience working with a tool. Building features with it. Debugging it. Supporting the thing in production. These things take time. But sure, she knows SQL if she can pass a cert I guess.

BidEvening2503@reddit

What happened to learning as we go? Human memory is finite. Having the opportunity to solve similar problems isn’t the same thing as being able to do similar things in the future

I don't know what this means exactly, but I tend to agree that a software engineer would be expected to pick up and use any tool within a short amount of time. That same engineer would not claim to know, eg Rust, even after shipping some small pieces of code with it.

budding_gardener_1@reddit

That's why we typically talk about years of experience working with a tool.

Years of experience with a tool is a stupid metric to use to assess competency.

Works for pilots.

Well, the last time I checked - pilots aren't the ones building enterprise software and software engineers weren't flying planes for a living

bland3rs@reddit

Knowing SQL is being able to fulfill a request such as “get me a list of customers and the number of orders they made, bucketed by year.”

Knowing SQL well is being able to do the more complex requests (e.g. involving windowing or recursion) AND being able to understand how to write (reasonably) fast(er) queries.

metaphorm@reddit

I think this question is about degrees of knowledge. This is a hard problem and doesn't have a widely agreed upon answer for any domain. It's even harder in the software field because things are constantly changing and evolving, so knowledge also has a freshness/staleness problem associated with it.

Here's an attempt at a loose framework though. Levels of knowledge in software technology:

basic minimal awareness of the technology. in SQL, I would associate this with "knows what a SQL database is, and has interacted with software with database integrations on a basic level (maybe ORM generated queries)".
foundational knowledge of the technology. in SQL, I would associate this with "knows and understand the important concepts in relational data design (normalization, different kinds of relations between tables, indexing) and can write SQL queries directly, without tooling support"
expert knowledge of the technology. in SQL, I would associate this with "years of experience in basic RDBMS design patterns and usage, competency at optimizing queries, functional understanding of data lifecycle management, and RDBMS operations"
deep knowledge of the technology. in SQL, I would associate this with "has written non-trivial ORMs (or similar) from scratch, has significant experience with both common and uncommon use cases and design patterns, understands some implementation details of the database engine (e.g. memory pages, on-disk vs. in-memory data representation, etc.)"
world class knowledge of the technology. in SQL, I would associate this with "is an active or past contributor to RDBMS engine code" or similar levels of hands-on involvement at the cutting edge.

No-Economics-8239@reddit

There isn't a technical definition for when you finally grok some new tech or feature or language. They are all rabbit holes that have no bottom. Even the creator of a given framework or language isn't going to know all the unintended features that power users will inevitably uncover.

There isn't any legal threshold to saying you 'know' something, regardless of context. It doesn't convey any specifics and could easily be construed as 'knowing of' something rather than being 'knowledgeable about' something. In the Before Times, there was the Geek Code, which had five levels of knowledge. From know the mere basics of familiarity up to technical mastery. But all these levels are relative and subjective.

It doesn't become meaningful until you start detailing what you've done in the language. Years of use by itself are usually not very helpful if they don't include context about specifics. Actual implementation details are where you can detail your degree of understanding.

lastPixelDigital@reddit

I would probably say a person knows something when they can work alone and produce satisfactory results on the tasks given to them. It's a vague sounding answer, for sure. But with this it means they can: - understand the basics to intermediate level - use the tool and trouble shoot when they don't get the expected results - produce the desired outcome

Being an expert, I would say is much more in depth.

For SQL, I think they should know: - the available types of data - creating and dropping DBs, Tables. Could also include views - Altering tables - Select, update, and delete. - Joins. - Transactions. - understanding when and why to use indexes - general understanding of aggregate functions - database normalization and ACID

hitanthrope@reddit

Saying you "know" something, as you allude to is fairly meaningless. It's the same kind of thing as when people ask, "How long will it take me to learn X?". There is no 'definition of done' for a statement like this.

You probably need to insert some context. Telling somebody in a job interview, where you might reasonably be expected to demonstrate an advanced understanding, than you "know SQL" has a different threshold than telling somebody you just met at a party. You might make some weird friends though, depending on the party.

Anybody who actually cares or values whether you have a particular skill will want to validate it anyway, so it doesn't really have practical consequence.

What you should never do, (and a great many recent grads need to be told this), is draft up a resume with a bunch of complex technical skills and score yourself 5/5 or 10/10 in them. The reason for this is you will eventually meet an asshole like me who enjoys making people prove these claims :).

Seriously, just say you know something when you feel confident saying it. In a room of people you know to be experts in that thing, you just add a caveat or two. No big deal.

Antique-Stand-4920@reddit

Instead of having knowledge, I like to consider how well a person can apply that knowledge. For example, knowing some SQL doesn't mean a person is good at translating requests for data into SQL queries. I'd want a person to show me that they can understand and execute some data requests within a reasonable amount of time.

AhoyPromenade@reddit

I would say that one of my frustrations dealing with recruiters and candidates is that people don’t know what they don’t know and so assessing knowledge ends up being really difficult and only comes out at interview stage with someone technical.

So if I was to ask someone about whether they “knew” SQL all the things you mentioned are important but are like the bare minimum for someone to say they knew SQL. It’s enough to do some straightforward but still valuable work. But it’s not enough knowledge to assess whether someone is “good” at it. There’s a huge amount of depth in every area you touch. Some of it may not be relevant, and not everyone will know everything. For example though, it’s useful information to me to know whether someone has experienced having to deal with auto vacuum in Postgres, what fragmentation is caused by and thus that they have a mental model of databases and their performance characteristics. That is easy to check by asking probing questions and it tells you a bit about the responsibility levels in their current and previous roles and whether they were actually able to perform at those levels too. I regularly interviewed people a few years ago who said they were an expert in Python for e.g. but who barely know the language or its ecosystem. I don’t try to be a dick about it or anything but it’s important to work out when trying to assess people’s levels and where they would fit in skills wise.

For me when hiring people who aren’t junior, usually what I want to know is whether someone can start from scratch, know what a standard project looks like, set one up sensibly with reasonable structure, can start writing code without tons of guidance, and can use sensible paradigms with that technology e.g. picking well tested and well known libraries, not some project with 15 stars on GitHub and no tests. Then that they can come up with a maintainable structure, DRY enough but not too much.

CelebrationConnect31@reddit

I think at some point you need to make a cut-off what is general knowledge vs specializiied knowledge. When somebdoy says I know sql it means what you said: I have good understanding of technology to work with it as expected by technical worker. It doesnt mean I know how to optimize sql queries on advanced level. Same with java. I worked with java for 7 years. I have basic understanding of gc, memory model, hot spots but I won't be able to optimize jvms parameters. Java knowledge does not encompass by default advanced jvm configuration knowledge.

ClydePossumfoot@reddit

IMO I “know” something and am confident saying that if I can go off on my own and solve a problem[0] with said something without another person’s assistance[1]

[0] solve here means that if someone else who knew the said something saw my work they’d at least nod their head and be like “looks good to me” and not “wtf is this shit?”

[1] googling, stack overflow, and reading references don’t count here. You’ve gotta at least be able to understand the problem and solution space enough to judge the stuff you’re reading and use it appropriately to solve the problem.