>above average student (average scores are made public)
>apply for internship
>virtual internship arranged
>no behavioral questions, no introductions, literally just "here's this hackerrank link, go solve the problem"
>can't solve because my classes haven't even made it to hashmaps and whatnot
And I'm ahead of most of my classmates just by landing an interview. What can I do to maximize my chances of being successful within the tech industry while still a student?
 CRIME Shirt $21.68 |
 UFOs Are A Psyop Shirt $21.68 |
CRIME Shirt $21.68 |
>can't solve because my classes haven't even made it to hashmaps and whatnot
>above average student
>above average student can't anything learn on his own
are you an above average student in India or Subsaharan Africa?
Nah, he's probably a muslim blood cult zealot.
They're all low IQ inbreads.
Hashmaps are peak cargo-cult programming.
Also being good in school does not mean you are a good developer. Working in software development is more about architecture then actual implementation. Also it feels like a never ending string of group projects.
>Hashmaps are peak cargo-cult programming.
Are they not inherently faulty to some degree?
I'm squeezing an infinite possibility of keys into a memory-constrained amount of hashes, the probablity of at least one collision must approach 1.
Am I wrong?
You could probably calculate the probability.
Personally I never needed them to actually solve a problem. I guess they are en vogue with the leetcode gang because they are far left on some bell curve nobody in the real world cares about.
They're used in e.g. dictionaries in higher level languages, I suppose.
I've used them in Arma, the SQF scripting language added hashmaps in v2.0-something and using the built-in hashmap then reduced an algorithm's execution time from 30 to 2 seconds.
Essentially, it's now a dictionary instead of searching an array for a string match.
But it's all black magic to me
>an infinite possibility of keys into a memory-constrained amount of hashes
just looms in my head like a block.
Wait, I think I figured it out, instead of pre-allocating the needed space, you allocate as necessary and leave it to the user to ensure memory is not out of bounds.
So I have a hash function that e.g. returns "mzh" and an array a-z for the first one, allocate another such an array a-z to which "m" in the first digit points to, and so on and so forth until the last hashsymbol where the data itself is pointed to.
>leave it to the user to ensure memory is not out of bounds
splendid idea anon
You hash the key, and then if theres already an entry in a bucket you just do a sorted insert of the data into the bucket of the hash index. You don't typically store the entries in the hashmap directly into the array, you store them in the array that's within the the "hashable set" or whatever.
Hashmaps lose speed when there's a lot of collisions because there's probably a lot of string comparisons that are just slow. If there's only 1 entry in each bucket then it just has to pick that one.
I'm not good at explaining stuff but hashmaps are fairly simple at a high level.
>I'm squeezing an infinite possibility of keys into a memory-constrained amount of hashes, the probablity of at least one collision must approach 1.
>Am I wrong?
You're not wrong, but we in practice we don't have infinite data, and all it it takes to have collision-less hash table is to have as many keys as values
that's not even a hashmap anymore it's a fricking lookup table
Well yes you morono, because they're the exact same data structure, namely a dictionary
they're just different implementations of it
i'm just saying why even bother with hashing at that point
Addendum: If I have 500 possible hash values and 501 keys, is the probability of collision not actually automatically 1? It approaches 1 beforehand, as hashing algorithms are probably not ideal.
>I'm not good at explaining stuff but hashmaps are fairly simple at a high level.
Yeah, no, Anon, that was a good explanation to me. I'd call it collision-protection.
would work by pointing directly to the userdata, but would probably be (much?) more memory intensive, but undoubtedly faster.
It's basically only memory jumping hoops, zero computation.
If at compile time you know you have 501 keys, then there is no reason to use a hashmap. Hashmaps are only useful for datasets of varying sizes with arbitrary keys defined at runtime.
If you just want a key to value map then implement a lookup table or something. Or just use numerical indices like a sane person because strings slow everything down.
im tired of you morons talking about things you dont understand
they're usually the easiest solution to most problems, but rarely the best.
have you heard of google?
When I run into roadblocks I type the subject that i'm struggling and look for content designed to explain or teach the concept.
>200k/yr BTW
Academic marks have nothing to do with the working industry. Most schools don't teach you even 1/4th of what you need to produce software.
Companies are not going to care if you score well on someone's curriculum if it has no bearing on the work you'll be doing everyday.
You're good at school? That's nice, but are you good at the job I'm hiring for?
The average student in a CS program is, to be frank, moronic. 90% of these people will never become software engineers and 90% of the remaining 10% people will never break 100k. If you want to be successful in CS, you have to be the 1%.
I'd suggest making sure that you know your entire undergrad curriculum, then start working on a postgrad stuff.
Most people I know who are successful in tech do this:
High School: Learn complete undergrad CS curriculum, often some post-grad stuff as well and projects (actual projects, not cookie cutter webshit)
Freshman: Post-grad stuff/projects
Sophomore/Junior: Research/Internships
Senior: Research/Internship, possibly with return offer
You're already behind (as evidenced by the fact that you didn't know enough to pass the interview.) Better get cracking. If you're a junior it's too late, but if you're a freshman or a sophomore if you grind hard you can likely scrape into a mediocre tech job, and from there work your way up the ladder.
Growth isn't linear, things can progress a lot faster than you think they do.
I suggest you to try this: https://codeforces.com/contest/1946/problem/E
It's my fav problem <3
Has a really beautiful solution IMO