I did Hack Reactor in 2013. My background prior to that included a year of college CS and a couple of years doing recreational coding challenges like Project Euler problems. I had been dreaming of a professionalizing my coding skills and getting a tech job, and Hack Reactor did that perfectly for me. I had several offers upon graduation and took one at a startup I was really passionate about. While there, I was able to work on and later lead a variety of projects, including a complete rewrite of our frontend and a large-scale database migration.
I'm now in the middle of my second job search after 3 great years there. I'm generally interviewing for "Senior Backend"-type roles that expect 3-5 years of experience. However, I have seen some prejudice against bootcamp graduates, and tend not to reveal that I went to one unless pressed. Otherwise, it's easy to be pigeonholed as unqualified to work on the backend. Interviews have gone well and I've made it to most of the onsites, with two offers already.
I don't keep up with most of my cohort but the ones I know are still engineers and generally seeing career success, though a few people have struggled. However, I think the market was much easier for bootcamp-level grads in 2013 than it is today. I don't recommend bootcamps as strongly anymore, especially for people with very little previous coding experience.
We're looking to hire one or more full-stack engineers at ClassDojo, a Y-Combinator education technology company beloved by elementary school teachers (our app is actively used in over 90% of US K-8 schools). https://www.fastcompany.com/3065654/innovation-agents/classd...
Our stack is node/mysql/mongo/react. You should have at least 1-2 years of experience and a desire to work across the whole stack.
You can apply through the link above or by emailing me at peter@classdojo.com
Thanks for referencing my earlier post in the article! We use the "sliding window log" you described at ClassDojo, but your more memory-efficient approach looks great.
I believe certain signals are transmitted from your phone even if it's "off". Removing the battery might stop some of them, but even this supposedly doesn't stop everything.
About Us: We're a small team of ~20 people (10 engineers) making one of the world's most popular education apps. Help make classrooms happier and more positive with engaged parents and students, and get handwritten fan mail from teachers and students every day on account of your impact. We value collaboration, joint ownership of product, and high test coverage.
Roles:
- Senior Backend Engineer: expand our service-oriented architecture to help us scale to tens of millions of active users. Work in node.js with some Go on the horizon.
- Lead Android Engineer: take charge of our app which, each September, is in the top 50 worldwide.
Honest question: What's the use of compressing the counter for n smaller than log(n) bits? Even if you were counting something on the order of 10^30, log n is only around 100 bits. Wouldn't storing the algorithm take more space than you'd save through this counter?
For example, I might want an approximate counter of number of reads of each row of a cache. Assume my cache has a lot (millions?) of rows, each of which stores a small amount of data. With the given algorithm, I could store the counter in a single byte per cache row. Without it, I'm probably looking at 4 or 8 bytes. It adds up.
As an aside, the article presents an alternative in which you have multiple simultaneous counters and take the median of the results to get finer bounds. I wonder how this compares with just using a single counter containing more bits and modifying the probability that you "increment" the counter?
[Edit: I realize the answer to my question about modifying the probability of a single counter may be that it's hard to get an unbiased random source for probabilities of 1/3, 1/5, etc.]
Algorithm is re-usable, i.e. you can count multiple events with the same algorithm. This way you get an array of bytes, or even half-bytes, instead of an array of very long integers. Can be useful, especially for embedded systems.
I'm now in the middle of my second job search after 3 great years there. I'm generally interviewing for "Senior Backend"-type roles that expect 3-5 years of experience. However, I have seen some prejudice against bootcamp graduates, and tend not to reveal that I went to one unless pressed. Otherwise, it's easy to be pigeonholed as unqualified to work on the backend. Interviews have gone well and I've made it to most of the onsites, with two offers already.
I don't keep up with most of my cohort but the ones I know are still engineers and generally seeing career success, though a few people have struggled. However, I think the market was much easier for bootcamp-level grads in 2013 than it is today. I don't recommend bootcamps as strongly anymore, especially for people with very little previous coding experience.