Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

They don't even know the fundamentals

blog.royalsloth.eu

Post reply on HN
Print view View original

201–210 of 323 posts

Re: They don't even know the fundamentals

#201

Post by dkarl »

> Yet, despite coming up with a distributed archiving system that works in production, I wouldn’t be able to explain from the top of my head what the ACID term means.

You could probably talk about the important properties of interactions with a datastore well enough to please a reasonable interviewer. Why assume they aren't reasonable? I really hate the trope of, "XYZ came up in an interview, and therefore I assume the interviewer is making hiring decisions according to a such-and-such rigid criteria I imagined when I went home afterwards."

(The conversation with "Joe" of course is imaginary, because you wouldn't already be started with interviews if you hadn't talked about how you were going to evaluate candidates. If this conversation happened in real life, the blog post would be about planning for interviews and not going rogue with your interview agenda when you're part of a team process.)

Interviews are designed to figure out where a candidate is with their knowledge, all the way from "they don't know anything about databases" to "they can write a little bit of SQL with help" to "they have 10 years of experience with the database we use for our OLTP, and our expert had a great conversation with them about the technical details of a quirk that bit us in production last week." Depending on the position, these might all be acceptable levels of knowledge for a position, not to mention that companies are often hiring for multiple positions, not all of which have been publicized yet, and are often open to redefining a role for the right candidate.

Every candidate has their own idiosyncratic mixture of strengths and weaknesses. Candidates have a hard time believing it, but a hard or unexpected question is usually probing for strength, not weakness. If interviewers only asked questions that a minimally qualified candidate can answer, they would miss your strengths and undervalue you as a potential hire.

Re: They don't even know the fundamentals

#202

Post by markus_zhang »

EdwardDiego wrote: post #192
markus_zhang wrote: post #164

Earlier quoted context omitted.

I think it's a bit too specific. But for sure someone can relate to similar experience. Something like "For sure I haven't dealt with Druid specifically but in my job I tackled with a similar problem for a different set of tools...". BTW from my experience we are streaming a lot of data (similar to 10TB but definitely more) produced in JSON then converted to Avro using Spark and finally loaded into Vertica and the an…

> Because the wording seems to indicate that Druid is not particularly good with ad-hoc analysis Bingo ;) I was trying to phrase it like I've heard people do so in interviews. And tbh, a candidate saying "I'm not familiar with Druid, but it sounds like you can't use it do ad-hoc queries with it? Can you tell me more?" would be a very good sign.

Interesting. I'll look into it as it intrigues me. One thing about DE is that we now have so many tools to choose from :/

Re: They don't even know the fundamentals

#203

Post by OctopusLupid »

sinsterizme wrote: post #176
dan-robertson wrote: post #145

Earlier quoted context omitted.

Just say everything is O(2^N) and you’ll be technically correct most of the time. If the interviewer says that it’s wrong, they don’t know their fundamentals.

Can you explain? I clearly forgot the fundamentals :p

(Taking a Algorithms course now, so I might get it wrong, if so, RIP to my finals in a few weeks)

I think O notation represents the upper bound, so a complexity of N can also be said as O(N^2) or O(N^3), but that isn't particularly useful.

In other words, if f(x)/g(x) inf, then f(x) = O(g(x)).

Then there's omega-notation (lower bound, f(x)/g(x) > 0) and theta-notation (both lower and upper bound, 0 < f(x)/g(x) < inf).

Re: They don't even know the fundamentals

#204

Post by markus_zhang »

EdwardDiego wrote: post #196
markus_zhang wrote: post #169

Earlier quoted context omitted.

But how can I be familiar with S3 without any data engineering work? Or maybe I should put it like this, what exactly does "familiar with S3" mean? Does it mean that I used it to store something (I mean even a non-programmer can do that), or that I should be able to manipulate (i/o) the store using Python with Boto (Again this can be done with a tutorial), or something else? I believe that "something else" usually in…

> But how can I be familiar with S3 without any data engineering work? ... you don't need to be in data engineering to use S3. And can you be familiar with it? Read the docs, write some code.

OK I see what you mean. So it's probably close to the second definition.

Re: They don't even know the fundamentals

#205

Post by kayodelycaon »

gameswithgo wrote: post #187
kayodelycaon wrote: post #173

Earlier quoted context omitted.

I have a computer science degree from 10 years ago and I couldn't tell you how to implement one. I vaguely know the general principles but I'd have to sit down and start from scratch on how to implement one. Why? The only time I knowingly used them is with database indices. For everything else I do, they are an unnecessary implementation detail. It doesn't matter what Ruby's Set uses.

People who make this comment, I generally don't believe you, or don't believe you have done any programming. If I put a gun to your head and give you an hour, you can't make a node that points to two other nodes of the same type? If you really can't, you should get familiar with how data can point to other data, it is fundamental and done all the time.

Do you want me to show you a single-linked list or a double-linked one?

    [data, *next] [data, *next] [data, *next] [data, *next]
If next is null (0), it's the end of the list.

Re: They don't even know the fundamentals

#206

Post by smcl »

sushsjsuauahab wrote: post #175
smcl wrote: post #152

Earlier quoted context omitted.

That's true to some extent, but I am quite sure even the worldest-of-class engineers have tripped up on a question or two and went on to get a rejection. If such people truly are talented then they'll have no trouble getting hired elsewhere and the companies in question would be blissfully unaware what they missed out on.

Such companies deserve to fail if so, as the supply of such engineers is limited and allegedly they need such engineers to survive :) Think Sears vs Amazon-- which company would know what gold was if they fell into a pile of it?

I am not sure the failure of any company has ever hinged on the hiring decisions of a few developers. If you take a look into the downfall of Sears you'll see long-term strategic missteps that aren't related to recruitment in their software engineering teams.

Also I don't think a company deserves to fail if they've got a bit too much faith in a slightly flawed recruitment process. The entire point of us sharing posts like this on here and discussing them is to learn and even help each other, isn't it?

Re: They don't even know the fundamentals

#207

Post by magicalhippo »

jhgb wrote: post #98
nostrebored wrote: post #73

Earlier quoted context omitted.

Because an implementation of a binary tree is dead simple.

You mean a naive one, that is, a useless one...or a practical one? Such as, at least something like LLRB?

This is another point in which this can be a good interviewing question. For certain jobs you don't want someone who just forges ahead with an unclear specification.

That said, for most dev jobs implementing a binary tree isn't necessary knowledge. But if I need a dev who can get their hands dirty I would be weary of hiring someone who can't take a decent stab at it during an interview.

Re: They don't even know the fundamentals

#208

Post by magicalhippo »

tchalla wrote: post #154
smallerfish wrote: post #135

Earlier quoted context omitted.

Well hopefully there's some layering in the question if it matters to the job. If you have an engineering position in which a high degree of CS competence is required and the candidate can't even make it past the initial layer of "regurgitating binary tree operations" then you have the wrong candidate.

> If you have an engineering position in which a high degree of CS competence is required and the candidate can't even make it past the initial layer of "regurgitating binary tree operations" then you have the wrong candidate. Or you have a candidate who understands binary trees, can implement it but can't regurgitate binary tree operations from the top of their memory.

For me the point would be that a no-frills binary tree is simple enough that any dev qualified for such a position should be able to figure out what needs to be done from the specification, without needing to regurgitate anything.

If they can't recall how balancing is done that would be fine with me, as long as they mention it.

Re: They don't even know the fundamentals

#209

Post by 7thaccount »

fkarg wrote: post #112
7thaccount wrote: post #93

The fundamentals are important. In my field of engineering (not software) ignorance of the fundamentals means not knowing how to properly run studies, not being able to accurately make recommendations, not understanding proper cause and effect, not knowing the relevancy of the various settings of the industry standard software...etc etc. It's really hard to find that in new graduates and there is virtually no decent…

I would be interested what field you're talking about - could be any rather specialized field, really

Power grid operations. Things are enormously complex (business rules, standards, software stacks, processes, massive data sets, and of course the fundamentals).

Yeah, maybe this is all fields, which is a shame.

Re: They don't even know the fundamentals

#210

Post by dan-robertson »

OctopusLupid wrote: post #203
sinsterizme wrote: post #176

Earlier quoted context omitted.

Can you explain? I clearly forgot the fundamentals :p

(Taking a Algorithms course now, so I might get it wrong, if so, RIP to my finals in a few weeks) I think O notation represents the upper bound, so a complexity of N can also be said as O(N^2) or O(N^3), but that isn't particularly useful. In other words, if f(x)/g(x) inf, then f(x) = O(g(x)). Then there's omega-notation (lower bound, f(x)/g(x) > 0) and theta-notation (both lower and upper bound, 0 < f(x)/g(x) < inf)…

Yeah this is right. Big O can be thought of as meaning “eventually always smaller than a multiple of” so f(n) = O(g(n)) as n -> inf means that there is some N (the “eventually” part) and M (the “multiple of” part) such that, for every n > N, |f(n)| < M g(n).
Post reply on HN