Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
- Get invited to apply to job
- Technical interview, guy shows up late starts small talk wasting time and gives me the exercise
- Start implementing the first algorithm, finish it passing min test cases then realize there's a solution that would make both algorithms a breeze
- I pitch my solution realizing there's no much time left, cuz we lost almost 20 min of my test hour talking about BS plus the almost 10 min he arrived late, and reassure the interviewer it can be developed faster
- Interviewer says it doesn't matter, we should finish edge cases
- Kay no problem, finish the first algorithm successfully and explain pitfalls on the second part with the current implementation
- I tell him there's a better solution but he doesn't seem to care, he says time's up
Now here's the funny part.
I get called by the recruiter today (2 weeks later) and she says "They are happy with your soft skills but feel there are some gaps with your coding, they would like to repeat the technical interview because they didn't feel there was much time to assess the 'gaps' ".
Interviewers, either I'm competent enough to work for you or not, your tests must be designed to assess that, if you see you can't fit the problem you want in the time you have left change the problem, reschedule or here's an idea...LEAVE THE BS CHITCHAT TILL THE END AND START THE INTERVIEW ON TIME. When I do interviews I always try to have one complete free hour and a one algorithm exercise because I expect the candidate to solve it, analyze it and offer alternatives or explain it, I've never had someone finishing more than 2 an hour.
You can keep your job I'll keep my time. I'll write a similar problem on the comments to pass on the knowledge for people who enjoy solving these kinds of problems, can't give you the exact same thing, also tip guys don't do NDA's for interviewing it makes no fucking sense trust me no one cares about your fizz buzz intellectual property.
13 -
Job posting: "we require 1.5 years of experience in iOS development"
Also job posting: *doesn't mention a requirement for a degree*
Me: "Cool, this looks exactly like a job for me, I'll send them my résumé!
Recruiter returns to me a day after with this:
"You said you have no work experience, we said in the posting that you need to have 1.5 years of work experience"
THE JOB POSTING DOES NOT MENTION THIS ANYWHERE, THEY ONLY MENTION EXPERIENCE IN IOS DEVELOPMENT
WHY MAKE IT SO AMBIGUOUS AND THEN CHANGE YOUR STANCE
When I finally get a fucking response from a recruiter after sending my résumé to dozens upon dozens of companies, it's a bullshit response.
FUCK YOU.
Note: I am aware of the massive amount of AltRant crashes, I am sorry for making it worse. I need to work on 2 more major final tests that I must pass, but I think I will start fixing some of the crashes today.56 -
Two big moments today:
1. Holy hell, how did I ever get on without a proper debugger? Was debugging some old code by eye (following along and keeping track mentally, of what the variables should be and what each step did). That didn't work because the code isn't intuitive. Tried the print() method, old reliable as it were. Kinda worked but didn't give me enough fine-grain control.
Bit the bullet and installed Wing IDE for python. And bam, it hit me. How did I ever live without step-through, and breakpoints before now?
2. Remember that non-sieve prime generator I wrote a while back? (well maybe some of you do). The one that generated quasi lucas carmichael (QLC) numbers? Well thats what I managed to debug. I figured out why it wasn't working. Last time I released it, I included two core methods, genprimes() and nextPrime(). The first generates a list of primes accurately, up to some n, and only needs a small handful of QLC numbers filtered out after the fact (because the set of primes generated and the set of QLC numbers overlap. Well I think they call it an embedding, as in QLC is included in the series generated by genprimes, but not the converse, but I digress).
nextPrime() was supposed to take any arbitrary n above zero, and accurately return the nearest prime number above the argument. But for some reason when it started, it would return 2,3,5,6...but genprimes() would work fine for some reason.
So genprimes loops over an index, i, and tests it for primality. It begins by entering the loop, and doing "result = gffi(i)".
This calls into something a function that runs four tests on the argument passed to it. I won't go into detail here about what those are because I don't even remember how I came up with them (I'll make a separate post when the code is fully fixed).
If the number fails any of these tests then gffi would just return the value of i that was passed to it, unaltered. Otherwise, if it did pass all of them, it would return i+1.
And once back in genPrimes() we would check if the variable 'result' was greater than the loop index. And if it was, then it was either prime (comparatively plentiful) or a QLC number (comparatively rare)--these two types and no others.
nextPrime() was only taking n, and didn't have this index to compare to, so the prior steps in genprimes were acting as a filter that nextPrime() didn't have, while internally gffi() was returning not only primes, and QLCs, but also plenty of composite numbers.
Now *why* that last step in genPrimes() was filtering out all the composites, idk.
But now that I understand whats going on I can fix it and hypothetically it should be possible to enter a positive n of any size, and without additional primality checks (such as is done with sieves, where you have to check off multiples of n), get the nearest prime numbers. Of course I'm not familiar enough with prime number generation to know if thats an achievement or worthwhile mentioning, so if anyone *is* familiar, and how something like that holds up compared to other linear generators (O(n)?), I'd be interested to hear about it.
I also am working on filtering out the intersection of the sets (QLC numbers), which I'm pretty sure I figured out how to incorporate into the prime generator itself.
I also think it may be possible to generator primes even faster, using the carmichael numbers or related set--or even derive a function that maps one set of upper-and-lower bounds around a semiprime, and map those same bounds to carmichael numbers that act as the upper and lower bound numbers on the factors of a semiprime.
Meanwhile I'm also looking into testing the prime generator on a larger set of numbers (to make sure it doesn't fail at large values of n) and so I'm looking for more computing power if anyone has it on hand, or is willing to test it at sufficiently large bit lengths (512, 1024, etc).
Lastly, the earlier work I posted (linked below), I realized could be applied with ECM to greatly reduce the smallest factor of a large number.
If ECM, being one of the best methods available, only handles 50-60 digit numbers, & your factors are 70+ digits, then being able to transform your semiprime product into another product tree thats non-semiprime, with factors that ARE in range of ECM, and which *does* contain either of the original factors, means products that *were not* formally factorable by ECM, *could* be now.
That wouldn't have been possible though withput enormous help from many others such as hitko who took the time to explain the solution was a form of modular exponentiation, Fast-Nop who contributed on other threads, Voxera who did as well, and support from Scor in particular, and many others.
Thank you all. And more to come.
Links mentioned (because DR wouldn't accept them as they were):
https://pastebin.com/MWechZj912 -
Lessions I learned so far from my first big node/npm project with tons of users:
1) If you didn't build something for a while, expect 3 hours of resolving version conflicts for every two weeks since the last build.
2) Even if the tests pass, run the containers on your own machine and make sure that the app doesn't randomly crash before deploying
3) Even if the app seemed to work on your own machine, run the tests again in an environment mimicking prod at most 15 minutes before replacing the running containers.
4) Even if all else indicates that the app will work, only ever deploy if you expect to be available within the 4 hours following a deployment.
5) Don't use shrinkwrap for anything other than locking every version down completely. A partial shrinkwrap will produce bugs that are dependent on the exact hour you built the app _and_ the shrinkwrap file, and therefore no one will ever have seen them other than you.
6) Avoid gyp, and generally try not to interface too much with anything that doesn't run on node. If parts of your solution use very different toolchains, your problems will be approximately proportional to the amount of code. And you'd be surprised just how much code you're running. (otherwise it's more logarithmic because the more code the less likely a new assumption is unique)
7) Do not update webpack or its plugins or anything they might call unless you absolutely need to
8) Containers are cool but the alpine ones are pretty much useless if you have even just one gyp module.
9) There's always another cache. To save yourself a lot of pain, include the build time in every file or its name that the browser can download, and compare these to a fresh build while debugging to assert that the bug is still present in the code you're reading
+1) Although it may look like it, SQLite is far from a simple solution because the code and the bindings aren't maintained. In fact, it'll probably be more time consuming than using a proper database.3
Top Tags
Weekly Rant
View