Chart: Seasonal search trends - <AUTHOR> http://www.google.com/trends?q=job%2C+diet%2C+drugs%2C+democracy&ctab=0&geo=all&date=all&sort=0 Google Trends is much more elucidating than Alexa. An extremely powerful tool for monitoring points of consciousness.
"Sex" is a particularly interesting argument: http://www.google.com/trends?q=sex%2C+porn&ctab=0&geo=all&date=all&sort=0
Note Ramadan: http://www.google.com/trends?q=sex%2C+woman&ctab=0&geo=SA&geor=all&date=all&sort=0 (...and the correlation between Saudi news stories including "sex" and "woman")
Can't wait for the Trends API. <comment><AUTHOR> Can't wait for the Google Trends API.

Holiday sex searches skyrocket, news stories plummet: [http://www.google.com/trends?q=sex%2C+porn&ctab=0&ge...](http://www.google.com/trends?q=sex%2C+porn&ctab=0&geo=all&date=all&sort=0)

Ramadan? [http://www.google.com/trends?q=sex%2C+woman&ctab=0&g...](http://www.google.com/trends?q=sex%2C+woman&ctab=0&geo=SA&geor=all&date=all&sort=0) (note the Saudi news correlation)

Edit: No coding over Christmas: [http://www.google.com/trends?q=html%2C+php%2C+javascript%2C+...](http://www.google.com/trends?q=html%2C+php%2C+javascript%2C+c%2B%2B%2C+perl&ctab=0&geo=all&date=all&sort=0)

</comment><comment><USER2> [http://www.google.com/trends?q=eggs%2C+roses%2C+tree%2C+turk...](http://www.google.com/trends?q=eggs%2C+roses%2C+tree%2C+turkey&ctab=0&geo=all&date=all&sort=0)

If you just look at the turkey trend you can see the difference between Thanksgiving (in the US) and Christmas (in the UK)

[http://google.com/trends?q=turkey&geo=usa&sa=N](http://google.com/trends?q=turkey&geo=usa&sa=N) [http://google.com/trends?q=turkey&geo=gbr&sa=N](http://google.com/trends?q=turkey&geo=gbr&sa=N)

But notice that Turkey is popular in the summer in the UK too. Could that be sun seeking holiday makers?

Another fun one is the Hajj (Muslim pilgrimage to Mecca)

[http://google.com/trends?q=hajj&ctab=0&geo=all&d...](http://google.com/trends?q=hajj&ctab=0&geo=all&date=all&sort=0)

If you look carefully you can see the date slowly changing year on year because the Hajj is determined by a lunar calendar.</comment>


Announcing Topaz: A New Ruby - <AUTHOR> http://docs.topazruby.com/en/latest/blog/announcing-topaz/ <comment><USER2> Completely unscientific, but if these outputs are any indication, this is going to be great news for Rubby users in the future...

      $ time ruby -e "puts 'hello world'"
      hello world

      real    0m0.184s
      user    0m0.079s
      sys     0m0.092s

      $ time ~/Downloads/topaz/bin/topaz -e "puts 'hello world'"
      hello world

      real    0m0.007s
      user    0m0.002s
      sys     0m0.004s

<comment><USER3> In order to eliminate the potential bias of startup time I run similar test in many iterations. Here's what I got:

        $ time ruby -e "10000.times { puts 'hello world' }" > /dev/null
        real    0m0.102s
        user    0m0.096s
        sys     0m0.005s

and

        $ time ./topaz -e "10000.times { puts 'hello world' }" > /dev/null
        real    0m0.098s
        user    0m0.071s
        sys     0m0.026s

Any idea why I don't see such big difference?

<comment><USER4> what is your 'ruby'?

<comment><USER5> Good question. How many shells is rbenv/rvm executing? Do you get similar results with an absolute path?

</comment></comment></comment></comment><comment><USER6> I'm all for new Ruby implementations, but be very careful about judging performance of an incomplete implementation.

It's "trivial" to make a fast language that looks quite a bit like Ruby. It is a lot harder that make a language that remains fast in the face of handling all the quirks of the full Ruby semantics, though, such as selectively handling the risk of someone going bananas with monkey-patching core classes that could happen at any "eval()" point.

<comment><USER7> What you just wrote is exactly what I've been telling people about every new "Python" implementation for the last 3 years. Believe me, I understand this argument completely, that's why I made sure we had all the hard bits (monkey patching core classes, eval, etc.) before I released this.

<comment><USER8> callcc?

<comment><USER7> no call/cc yet, I do have a branch with fibers, but I'm waiting for an RPython branch to land for that first.

</comment></comment></comment></comment><comment><USER9> For those with long memories there was a (in)famous _Topaz_ project in the Perl world. This was an attempt to implement perl5 in c++. It was abandoned however it did help kick-start Perl6 & Parrot.

refs:

\- <http://topaz.sourceforge.net>

\- _Topaz: Perl for the 22nd Century_ <http://www.perl.com/pub/1999/09/topaz.html>

\- _Historical Implementations/Perl6_ [http://www.perlfoundation.org/perl6/index.cgi?historical_imp...](http://www.perlfoundation.org/perl6/index.cgi?historical_implementations)

</comment><comment> lost-theory I will be the first to ask: why did Alex / the pypy devs start this project? I thought the three community funded ideas were great (STM, Python 3, and Numpy). What prompted this new project? Is it meant to attract new developers to pypy as platform for implementing languages? Is it a side project? Is it a long term project meant to become the premium implementation of ruby as pypy is becoming for python? Etc.

Not criticizing at all by the way, just curious about the motivation / background / context for the project, which is missing from the docs.

<comment><USER7> Hi to be clear, this is project undetaken by me (Alex) independently, it wasn't funded out of the PyPy funds or anything like that. There were 3 primary motivations:

a) Because it's fun

b) To prove RPython is a great platform

c) To mess with people's heads, it's crazy!

<comment><USER10> Hey Alex, let me tell you I completely understand points a) b) c) and more. It seems we started our competing Ruby on PyPy implementations at about the same time [0]! My goal was to build a robust and documented Ruby parser, and hope PyPy make it magically fast. To that end I embedded PLY and modified it to not require kwargs. Then a thunder of work fell from the skies, and I was just recently unearthing PyPy 1.9 to put the thing back on track.

Congratulations for the release :-)

[0]:

        $ ls -l playground/pypy
        total 29160
        drwxr-xr-x  12 lloeki  staff       408 18 Feb  2011 ply-3.4
        drwxr-xr-x  15 lloeki  staff       510  3 Apr  2012 pyby
        drwxr-xr-x  23 lloeki  staff       782 27 Mar  2012 pypy-pypy-2346207d9946
        drwxr-xr-x  18 lloeki  staff       612 27 Mar  2012 pypy-tutorial
        -rw-r--r--   1 lloeki  staff  14927806 27 Mar  2012 release-1.8.tar.bz2
        drwxr-xr-x  10 lloeki  staff       340  3 Apr  2012 unholy

<comment><USER10> Holy snakes[0]. It seems you pursued the exact same approach[1] as me :-)

[0]: [https://github.com/topazproject/topaz/blob/master/topaz/lexe...](https://github.com/topazproject/topaz/blob/master/topaz/lexer.py#L6)

[1]: <https://github.com/alex/rply>

</comment></comment></comment></comment><comment><USER11> It would be nice to see Rpython/pypy turned into a project not unlike WebKit where many different projects benefit from the same open-source core. If pypy is flexible enough to implement all of ruby and all of Python, has a reasonable amount of maturity, and is already rather fast it seems like a good candidate for such a thing.

<comment><USER10> Quick how-to:

1\. (optional) install PyPy "JIT compiler" binaries [0]

2\. get and extract the PyPy source[1] from bitbucket release packages, which includes the RPython translator, written itself in Python and, although working on CPython, best run under PyPy as installed on step 1.

3\. write a (R)Python module including a _def target_ returning the entry point function[2], and call the translator upon your module, like so:

        python ./pypy/pypy/translator/goal/translate.py example2.py

I wish getting the translator was more 'packaged' and did not involve getting the whole PyPy source but I hear this is in the works, and it is reasonably easy already. The hardest part is actually figuring the translator is not part of PyPy binary release, and that it's available straight from bitbucket.

[0]: <http://pypy.org/download.html>

[1]: <https://bitbucket.org/pypy/pypy/get/release-1.9.tar.bz2>

[2]: [http://morepypy.blogspot.fr/2011/04/tutorial-writing- interpr...](http://morepypy.blogspot.fr/2011/04/tutorial-writing-interpreter- with-pypy.html)

<comment><USER12> yeah, working on it, sorry :/

</comment></comment></comment><comment><USER13> Forgive me for asking what may be a very stupid question: Can someone explain to me the need for a Ruby interpreter built on top of Python? He mentions performance in the announcement, but is this really going to be faster than, say, MRI? Thanks in advance.

<comment><USER14> Think of Pypy as somewhat like LLVM, except the language it's built on is a subset of the python language, called RPython.

Although the most well-known language implemented in the pypy "vm" is python, the toolchain is completely language agnostic.

So, this is more akin to Apple writing a C interpreter on top of llvm than it is to building a ruby interpreter on top of python.

<comment><USER12> PyPy is totally not like LLVM in many regards. It targets a very different demographics. Some differences:

* RPython comes with a good garbage collector

* the language where you specify what's going on is RPython in which you write an interpreter. Then you get a JIT using a few hints. This is difference than "interpreter in C + compiler to LLVM" scenario by quite a bit.

* RPython comes with a set of data structures that are higher level (lists, dicts, etc.) and is a GCed language. JIT is also well aware of those.

<comment><USER15> Do you know what an analogy is?

<comment><USER12> I'm actually not a native speaker, so indeed, I might not know. I checked in the dictionary though. This is an analogy, but not a very good analogy, because of the reasons that I pointed out. Are you disagreeing with any particular reasoning there? Or should I just say "they're similary, but"?

<comment><USER16> An analogy does not require that the items involved actually be similar, only that the relationships in each are the same. For example, "Gasoline is to cars, as sunlight is to trees" is a perfectly good analogy, even though gasoline is nothing like sunlight, and cars are nothing like trees.

In much the same way, comparing "Apple writing a C interpreter on top of llvm" to "Alex Gaynor writing a Ruby interpreter on top of RPython" makes a _very good_ analogy, even though Apple is not much like Alex Gaynor, Ruby is not much like C, and PyPy is not much like LLVM.

<comment><USER17> A good explanation, and further, many times a good analogy _relies_ on the things being very different in every way _except_ for the one way it intends to emphasize. An analogy is often a way of saying: "Let's focus on this (often very abstract) aspect of interesting similarities. Yes, you can easily point out many other dissimilarities. That ease means I'm not talking about those aspects, so if we understand each other those don't even have to be mentioned."

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I'm curious to see how this compares to MRI/Rubinius/JRuby once it's feature- complete; the PyPy vs. CPython benchmarks these days are pretty convincing.

<comment><USER7> One of the major launch criterion was having "enough of Ruby that the performance won't change". What does that mean in practice? We have exceptions, we have bindings, and we have all manner of other obscure corner cases. Charles Nutter (JRuby dev) writes about this: [http://blog.headius.com/2012/10/so-you-want-to-optimize- ruby...](http://blog.headius.com/2012/10/so-you-want-to-optimize-ruby.html)

</comment></comment><comment><USER19> Does Topaz benefit at all from the work that's been done already on Rubinius? I seem to recall that Rubinius implements as much of Ruby in Ruby as possible. It seems like this would help Topaz as well in implementing the standard library. Or are the implementations different enough that this doesn't work?

<comment><USER20> One of the things to come out of the Rubinius project is RubySpec, which is pretty much a language spec in unit test form, and which be very useful to test Topaz.

</comment></comment><comment><USER21> I'm probably in the minority but I would love to see a dialect of ruby that has significant whitespace. Death to unnecessary 'end's

<comment> josh-j > Some observers objected to Go's C-like block structure with braces, > preferring the use of spaces for indentation, such as used in Python or > Haskell [braces are optional in haskell]. However, we have had extensive > experience tracking down build and test failures caused by cross-language > builds where a Python snippet embedded in another language, for instance > through a SWIG invocation, is subtly and invisibly broken by a change in the > indentation of the surrounding code. Our position is therefore that, > although spaces for indentation is nice for small programs, it doesn't scale > well, and the bigger and more heterogeneous the code base, the more trouble > it can cause. It is better to forgo convenience for safety and > dependability, so Go has brace-bounded blocks.

<http://talks.golang.org/2012/splash.article>

<comment><USER22> This.

Especially when writing a code generator. Targeting a significant whitespace language is potentially more tricky than one with explicit delimiters. I love the Haskell approach to this.

<comment><USER23> (For those who don't know, Haskell has an optional whitespace-significant syntax (which most humans use) as well as a brace-delimited syntax, and these are exactly equivalent.)

</comment></comment></comment></comment><comment><USER24> Sweet, I'm very interested in this. I assume this implementation has a GIL? Any word on how threads will be implemented?

<comment><USER7> No GIL. Also no threads yet :) We're going to wait to see how Armin's work on STM support pans out.

</comment></comment><comment><USER25> Implementing other languages on top of the PyPy toolchain is an interesting concept, and I'd like to see it happen more often. But calling this "Ruby in Python" is sure to invite flamewars from all sides. The actual Topaz site seems to be careful not to do this, but if this thread is any indication, a fair number of people are already mistakenly calling it that.

<comment><USER9> There are already a few other language _implementations_ on PyPy.

For e.g.

\- Javascript | <https://bitbucket.org/pypy/lang-js>

\- Smalltalk | <https://bitbucket.org/pypy/lang-smalltalk>

\- Schema | <https://bitbucket.org/pypy/lang-scheme>

\- Io | <https://bitbucket.org/pypy/lang-io>

<comment><USER26> \- Converge | [http://tratt.net/laurie/tech_articles/articles/fast_enough_v...](http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time)

</comment></comment></comment><comment><USER27> [http://blog.headius.com/2009/04/how-jruby-makes-ruby- fast.ht...](http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html)

At least once a year there's a maelstrom of posts about a new Ruby implementation with stellar numbers. These numbers are usually based on very early experimental code, and they are rarely accompanied by information on compatibility. And of course we love to see crazy performance numbers, so many of us eat this stuff up.

<comment><USER28> Given that the original article thanks the author of that post (Charles Nutter) by name, I think it's likely that Alex is aware of it.

</comment></comment><comment><USER29> If it doesn't have all of Ruby's weird features, claims of speed don't matter, because it's those weird features that make Ruby slow and hard to optimize.

</comment><comment><USER30> Could this lead to a runtime in which I can use really cool ruby modules from python and really cool python modules from ruby? I mean, seriously, these two languages both have some pretty awesome stuff, and regularly I say about one, "man I sure wish I could use $module from the other".

</comment><comment><USER31> Any reason for not targeting Ruby 2.0?

</comment><comment><USER32> Excellent news. I wish this project the best of luck. More competition in the Ruby implementation field is always a good thing for end users, it fosters innovation and provides choice and a good kick in the ass to everyone.

</comment><comment><USER33> I've been wondering why the tools the PyPy people have been building are not used to implement more languages. It's nice to see this happening. And it will be interesting to watch where this leads.

</comment><comment><USER34> Doesnt mention what the current status of topaz is with respect to <http://rubyspec.org/>

</comment><comment><USER35> I mean, it's cool that people want to expose Python's version of Rubinius as a building block to yet another Ruby interpeter, but, come on. Why is this a thing?! Why not waste time improving the JVM, contributing to Rubinius, patch the MRI, or a million other open source projects already tackling Ruby being "slow". By the way, has anyone else realized that, while Ruby is slow, _computers_ are getting faster for us too!

</comment><comment><USER36> Sounds really interesting, but we already have a dozen of incomplete alternative Ruby implementations...

</comment><comment><USER37> Just curious, for this project did you set out to write it in idiomatic ruby or idiomatic (R)Python?

</comment><comment><USER38> So Ruby on top of RPython on top of PyPy? Why not, but how does it compare to JRuby and Rubinius?

<comment><USER26> > So Ruby on top of RPython on top of PyPy?

No. It's Ruby in RPython, where PyPy is Python in RPython. The pypy project is currently in the process of splitting "RPython" (the VM-development framework) from PyPy (the Python VM) to make that clearer.

RPython is a general purpose, language-agnostic (ish?) core for implementing JIT-ed garbage-collected languages, it's kind-of similar to LLVM being a framework for implementing compilers.

(now because rpython is a proper subset of python you can run your rpython VM on a python interpreter without translation, but that doesn't give you any specific python bridge, in the same way coding your VM in C doesn't give you a c FFI for free)

<comment><USER39> But RPython used to be the reduced version of the Python language. What name do you give to the jit-compiler generator?

<comment><USER26> The same, as far as I've seen. RPython is both the VM-framework and the Python subset which exists within (and for) that framework (RPython is not considered and developed as a general purpose language, but as a language for building VMs within the RPython system/framework/toolset).

The important distinction really is between RPython (a language and framework for building virtual machines) and PyPy (a virtual machine implemented in/on RPython)

</comment></comment></comment></comment><comment><USER40> So... GIL?

</comment><comment><USER41> RPython is the new C?

<comment><USER42> In addition to fijal's comment: I also heard somewhere that RPython is a) not strictly specified and b) may change when needed without notice. So I would stay clear of it. :)

<comment><USER12> we removed that from the docs, it's kinda stable by now (but it's still an atrocious language to use, just beats C/C++ for that particular task by a lot)

<comment><USER42> Out of curiosity, whats so atrocious about it? The slow translation step or language idiosyncrasies?

<comment><USER7> Slow compilation, undocumented semantics, and most importantly: atrocious error messages..

</comment></comment></comment></comment></comment><comment><USER43> Topaz as a name? Seriously? (<http://topaz.sourceforge.net/>)

<comment><USER44> I find it odd that you link to a project that hasn't seen an update in the last 12 years. How old does a project have to be before it is considered "dead"?

<comment><USER45> The project is certainly dead, but it's also historically significant.

</comment></comment></comment><comment><USER46> Why not implemented on Erlang OTP? Ruby and Python share the same scaling issues, so I don't see a benefit it combining them or migrate from one to the other.

I also dislike the "high performance" claims without showing a single performance comparison. Not to mention the state of implementation completeness of the language.

<comment><USER12> I think you're missing the point. It's not written _in Python_. It's written i RPython, which is vastly different. Technology behind this and PyPy is the same, however there is no Python usage here.

Additionally, erlang has avoided scaling issues by being functional. This might be good or bad, depending on your viewpoint, but just implementing a ruby interpreter in erlang won't cut, because you're not answering any of the hard questions about the state. You might answer "meh, ruby is just a broken language", but well, this has nothing to do with that article.

<comment><USER47> "Topaz is written in Python on top of the RPython translation toolchain (the same one that powers PyPy)." [1]

"Topaz - An implementation of the Ruby programming language, in Python, using the RPython VM toolchain." [2]

[1] <http://docs.topazruby.com/en/latest/blog/announcing-topaz/> [2] <https://github.com/topazproject/topaz/blob/master/README.rst>

<comment><USER48> As RPython is a subset of Python, that statement is technically correct but misleading. Stating that Topaz is "Ruby written in Python" leads to the idea that it's written in / runs on _CPython_ , which is really not the case.

<comment><USER7> Well, it can be run on CPython if you wanted (that's how we run many of our tests). It's just crazy slow.</comment></comment></comment></comment></comment>


Scalaz: An Introduction to Scala's Library - <AUTHOR> http://www.stackmob.com/2011/11/why-stackmob-uses-scalaz-with-scala/

<comment><USER2> Scalaz's Validations are a fantastic way to handle error checking. We use them pervasively in Myna. The rest of Scalaz I have found less use for, but I think that's due to the domain. I imagine if we had more types of data they would be beneficial.

If you've just come to read the comments, be aware that this article is extracted from a more detailed work-in-progress <https://github.com/jrwest/learn_you_a_scalaz> If you have a serious interest in Scalaz you'll be better off reading that.

<comment><AUTHOR> Thank you for posting that link.

</comment></comment><comment><USER3> Orignal article's title is better. Scalaz is _a_ library for Scala, not "Scala's Library". There's some good stuff in there but it's a completely optional third-party library.

<comment><USER4> relevant exercises from one of scalaz' authors

<http://blog.tmorris.net/lifting-haskell-addendum/>

<http://blog.tmorris.net/lifting/>

and the applicative functor and following chapters in Learn you a Haskell (it wasn't real easy to navigate scaladocs, source, etc. Some folks used to just hoogle and then look for the same-named scalaz method

[http://groups.google.com/group/scala- user/browse_frm/thread/...](http://groups.google.com/group/scala- user/browse_frm/thread/2e93b614df487f86#)

and the scalac switches -explaintypes, -Ytyper-debug are kinda helpful.</comment></comment>


How long does it take to make a context switch? (2010) - <AUTHOR> http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html <comment><USER2> Pretty sure that he's just rediscovering what I did in lmbench back in the early 1990's. All written up and open source (and got best paper in the 1995 Usenix):

[http://mcvoy.com/lm/bitmover/lmbench/lmbench- usenix.pdf](http://mcvoy.com/lm/bitmover/lmbench/lmbench-usenix.pdf)

Edit: which now that I think about it, was over 20 years ago. Reminds me of something a friend (Ron Minnich) said long ago: people rediscover stuff in computer science over and over, nobody wants to read old papers. Or something like that. He said it better, I think it was something like "want to look smart? Just take any 5 year old paper and redo whatever it did, our attention span seems to be very short."

<comment><USER3> One reason people are reluctant to trust old sources (regardless of how well received they were at the time) is that software, operating systems and hardware all move at lightning pace. I've not read your paper, but I'm willing to bet enough has changed to warrant a new writeup talking about modern systems.

<comment><USER4> > operating systems and hardware all move at lightning pace

not really, last big leap was the ability to unlock gpu for stream processing, and that's it.

it's quite faster today as ten or one year ago, but at it's core it's still a von neumann machine and not much has been discovered ever since, mostly we're repackaging under a new name things that have been discovered in the 70s', like the thick vs thin client debate, which played more or less the same over and over again as the bottleneck switched from bandwidth to latency to client performances, the last iteration of which was ember and angular precompilation.

<comment><USER5> Some of the stuff goes back even further than that.

The thread on the Intel Optane stuff the other day had an interesting conversation about how you would program for such systems and someone said we already did, mainframes 50 years ago.

It's nice to see old ideas in a fresh context.

</comment></comment></comment></comment><comment><USER6> On the order of a millisecond. Which seems to me, way too slow in this day and age. The context switch has been a hard wad that chokes algorithms in unexpected ways, that are hard to diagnose.

This can be fixed with a different approach to CPU design? Most threads block on a semaphore-thingy or a timer or wait for io completion. If the CPU made those an opcode instead of a wad of kernel code, the switch could be reduced to a clock cycle (ns?)

How could this work? Maybe a global semaphore register where you Wait on a mask. Each bit could be mapped to one of those wait-condition. Another opcode would Set the bit.

To scale, the CPU would have to have not 2 or 4 hyperthreads but maybe 1000. So every thread in the system could be 'hot-staged' in a Wait, ready to execute, or executing.

There would still be cache and tlb issues, but they would be at the same level as any library call. They wouldn't include yards of kernel code messing with stacks and register loads and so on.

<comment><USER2> Hey, same Joe from Sun? If so, howdy.

On my i7-5930K I'm seeing 7-10 usecs, quite a bit better than a millisecond. Linus cares about this stuff, I'd be very surprised if he didn't measure it regularly.

<comment><USER6> Probably thinking of my brother, Rich?

usecs are a thousand times better than a ms of course. And a ns is a thousand times better than that!

</comment></comment></comment><comment><USER7> The author states:

>"In practice context switching is expensive because it screws up the CPU caches (L1, L2, L3 if you have one, and the TLB – don't forget the TLB!)."

How does a context switch "screw up" the L1 through L3 caches? Yes when there is context switch the TLB gets flushed and the kernel then needs to "walk" the page tables which is expensive and yes I can see the L1 needing to flush some lines but is that really screwing up the L1, L2 and L3 caches, the later two being fairly large these days?

<comment><USER8> A context switch changes the virtual-to-physical mapping. So, _if_ a cache uses virtual addresses for determining whether data is in the cache a context switch has to flush the cache.

It looks like (1) x86 is virtually indexed and physically tagged (i.e. you need a virtual address to find the cache line data might be in, and the physical address to check whether that line actually holds the data. See [https://en.wikipedia.org/wiki/CPU_cache#Address_translation](https://en.wikipedia.org/wiki/CPU_cache#Address_translation) for details))

(1) [http://www.realworldtech.com/sandy- bridge/7/](http://www.realworldtech.com/sandy-bridge/7/) but that may have changed, they might use different strategies for the various cache levels, or they may by now use some other tricks. Address translation is very hairy in multi-core systems.

<comment><USER7> >" So, _if_ a cache uses virtual addresses for determining whether data ..."

I was curious about your "if" caveat. I believe nearly all modern CPUs uses the virtual address as it doesn't know about the physical addresses no?

<comment><USER9> The CPU does know the physical address, because the MMU is part of the CPU; so you can have a physically indexed cache if you want. The problem is just that you can't do the cache lookup in parallel with the MMU physical-to-virtual lookup, so it's slower than if you used a virtually-indexed cache.

<comment><USER7> Sure, I didn't articulate my comment very well. I meant to say that the L1-3 caches operate on virtual addresses because they don't know the physical address but the MMU does since all memory access must transit through the MMU.

</comment></comment></comment></comment></comment><comment><USER10> Context switch in this article = within a computer and processor, not about psychology

<comment><USER11> Well this is a computer technology new aggregator isn't it? Not a psychology one.

<comment><USER12> To be fair, we do frequently talk about 'context switching' in a metaphorical sense of flitting between programming and conversations/meetings, or among different projects.

If anything, I think I agree with GP that it's more unusual to see the term used in the 'real' (not metaphorical) sense on the front page.

</comment></comment></comment><comment><USER7> The author also seems to be loose with specifying "context switches" where there is a difference between a context switch between two threads which shares everything except a stack and a context switch between two processes that have separate address spaces. Did anyone else find that odd?

<comment><USER13> Context: Linux.

<comment><USER14> Could you expand your response? I presume you are saying that since in Linux processes and threads are "the same" there is no need to distinguish whether the process being switched in shares the same address space. Does this mean that there is a missed optimization on Linux to preserve some virtually- addressed caches and tables when switching to thread/process that shares the same address space? Or that the terminology is correct, but that Linux already makes the possible optimization?

<comment><USER13> > I presume you are saying that since in Linux processes and threads are "the > same" there is no need to distinguish whether the process being switched in > shares the same address space.

That's right. Threads share everything but their stack.

> Does this mean that there is a missed optimization on Linux to preserve some > virtually-addressed caches and tables when switching to thread/process that > shares the same address space?

I'm not entirely sure I understand your question. What scenario do you have in mind?

</comment></comment></comment></comment><comment><USER15> > Applications that create too many threads that are constantly fighting for > CPU time (such as Apache's HTTPd or many Java applications) can waste > considerable amounts of CPU cycles just to switch back and forth between > different threads.

Completely wrong. Context switches happen at a set interval in the kernel. Creating more threads won't make context switches happen more frequently, each thread will just get a proportionally smaller share of CPU time.

Conceptually, the CPU scheduler can be thought of as a LIFO queue. An interrupt fires at a fixed interval of time and switches to the first ready thread (or process) on the queue.

What's more important is the fact that this queue is exactly equivalent to how 'asynchronous' operations are implemented in the kernel.

The only difference between creating threads and using async primitives is the thread prioritization algorithm. With threads you're using whatever scheduling heuristics are baked into the kernel, while with async you can roll your own. (And pay the penalty of doing this in usermode.)

<comment><USER11> Does the CPU interrupt threads running happily on cores even when there are no other threads which want to run or which have affinity that would allow them to run on that core?

But creating more threads will cause each to run slower as their caches are ruined by each context switch aren't they?

<comment><USER16> > Does the CPU interrupt threads running happily on cores even when there are > no other threads which want to run or which have affinity that would allow > them to run on that core?

Yes. Even if you are careful to ever run only one process (so: no monitoring, no logging, no VM's, no 'middleware', etc.) and limit the number of threads to strictly equal the number of processors, you still have background kernel threads that force your process to context switch.

<comment><USER17> Tough you can instruct the kernel not to run anything (not even interrupt handlers) on specific cores, except for manually pinned processes.

<comment><USER18> At a minimum you still need timer and TLB IPI shootdown interrupts hitting every core, just to have a working SMP system.

<comment><USER17> the cpu does need to handle IPI of course but not sure about timers.</comment></comment></comment></comment></comment></comment>


What I learned from spending 3 months applying to jobs after a coding bootcamp - <AUTHOR> https://medium.freecodecamp.com/5-key-learnings-from-the-post-bootcamp-job-search-9a07468d2331#.uwwwin7a8 <comment><USER5> Holy shit.

Is this some kind of a joke?

> Otherwise, companies automatically categorize us into junior developer roles > or tag us as "not enough experience."

??? What do you think you are after a TWELVE WEEK coding seminar (no matter how intense it was)? It looks frightening to me that he doesn't even know what "junior developer" really means. How ignorant can someone be to NOT think to be a junior dev right after "graduation". Like: I am taking a first aid course - but you have to call me doctor afterwards - otherwise I am pissed off!

> A study by Triplebyte has found that bootcamp grads are weaker in these > areas than computer science grads.

Really? No... This must be a lie!

No personal offence here, but honestly, I just can't imagine how a serious company with a certain degree of professionalism is going to hire people like him for a serious software engineering job (or similiar). But actually, if I think back, at my last job a couple of years ago we had a guy similar to him - it ended up giving him all the shitty work that wasn't too complicated and hadn't to much impact on the success of a project (some HTML & CSS stuff for the frontend) but nobody wanted to do (because it sucked). It took him hours and days to finish stuff someone of the rest of the team would have done in maybe half an hour.

I am also wondering about the reactions in the comments - also here on HN - interesting to see what kind if audience is hanging around here.

Anyway. Coding camps seems to be a good way to make money - for the organizers.

<comment><USER6> 100% this! The tech world is due an implosion if this continues, you cant have people with ZERO programming experience beyond a guided 12 week bootcamp being offered anything more than a Junior role??

This single sentence terrifies me:

"At Hack Reactor, we're trained to mask our inexperience. In our personal narratives, we purposely omit our bootcamp education."

$120k+ offer for 12 weeks experience - ridiculous, I hope he lasts 2 weeks

<comment><USER7> This is why you need good screening processes.

I on the other hand got taught to be able humble and make compromises especially when still being a junior. Looking back at my early days, when I wanted a position that I knew would change my career, I purposely asked for a lower salary in the beginning to compensate for my junior level or other skills (language for example when I moved into a country where I wasn't fluent yet), with a clause to bump it up to the level of other people when I can prove that I am on par with them and my lacking skills aren't a problem. It also showed the company that I was serious about wanting to work with them.

But man, 120k for 12 weeks of experience is insane. Sign me up for whatever bootcamp that was

<comment><USER8> Tip: You need a bootcamp in negotiations and selling yourself. Not in programming ;)

<comment><USER9> Good thing that's half (~6 weeks) of the curriculum at Hack Reactor!

<comment><USER10> (citation needed)

</comment></comment></comment></comment></comment></comment><comment><USER11> Are people in America seriously getting offers of $120k with no degree, no experience, and not even a side-project? That is mind-blowing.

In London, probably the biggest/richest market outside of USA, that sort of salary is beyond what most experienced developers get, even some very good ones.

I must be missing something here (some sort of bubble?) because I can't see how businesses can be profitable paying those sort of salaries to people who know almost nothing about professional programming. Either that or businesses in America are just waaaay ahead of Europe at turning code into cash.

<comment><USER12> Maybe I'm wrong but the salary an American gets is the whole package and they have to figure out their income tax, social security, etc. In Europe a good part of what the company pays for an employee is "hidden" but can account to 50%-100% of the gross salary you receive. So if you're getting 50k company is really paying 75k.

<comment><USER13> This is definitely not the case in Ireland, and I would imagine the rest of Europe. While there is the odd tax that an Employeer might need to pay on having an employee (probably benefits related), if a job says it pays, say, €60k, that's €60k pre tax. Tax is then deducted from that and you get your payslip which displays both pre and post tax numbers, and you receive the post tax amount.

<comment><USER14> I don't know about Ireland but that's definitely not true for Germany. While the amount usually talked about in negotiations is pre-tax (since people have differing tax rates due to children, marriage, etc.), there's a significant difference from there to the actual cost to the company.

In my company we pay about 25% on top for social security, worker's benefits, health insurance, etc. This is without any company-provided benefits such as trainings, conference allowances, holidays, etc.

<comment><USER15> Yeah, similar here in Lithuania. You can say there's three salaries a person can be valued at.

There's the official one which you would declare (pre-tax, or "on-paper"), the actual you get (post-tax, or "hands-on") and the one that shows your actual cost to the employer (pre-tax salary + 31% additional tax).

</comment></comment></comment></comment></comment><comment><USER16> On a related tangent, this is why it is so important to have a so called "Emergency fund"! An emergency fund is a little bit of money (often 1-6x average monthly expenses) such that if you get canned you can survive for 1-6 months without having to work so you can focus on applying for jobs and getting a new job without having to stress when your next bill is due.

I agree that 6 months living expenses is on the high side, but make sure to get at least >1 month of savings in ... make this a priority! I would argue to even do this before paying off your student loans. Why? Because this is such a 'small' sum of money which can really save your ass in the long run when something DOES go wrong. And if every month has a certain probability p of going down the shitters and you approach it like a geometric distribution then its a simple probabilistic (near) certainty.

Remember this: emergencies come unannounced (else they wouldn't be emergencies).

Get your emergency fund up and running !!

<comment><USER17> Depending on how often you expect to need an emergency fund and what the relevant interest rates are for illiquid saving (eg: paying down student loan debt) and unsecured borrowing, it may make more sense to have your emergency fund in an unsecured line of credit or credit cards.

Example with made-up numbers: Suppose you spend $2000/mo, you have an unused line of credit of $10000 @ 10%, your student loans are at 5%, and you are taking home $4000/mo. If you have an emergency that costs $2000 that hits your line of credit, that ends up roughly being an extra month servicing $2000 of debt at 10% instead of 5%. If you keep $2000 in cash instead of paying down student loan debt, that ends up meaning you service $2000 of debt at 5% instead of paying it down. These are roughly the same thing, so you wind up ahead if the LoC is sitting empty ~50% of the time.

Granted, these are much more favorable numbers than typical use of credit card debt, but the point remains - if you have access to credit on good terms, and you won't need it often, and you have good illiquid returns on excess cash, you ought to take a look at using credit to handle emergencies instead of cash.

<comment><USER18> Make sure to be diligent in checking the terms for that LOC. Many banks reserve the right to cancel it if there's substantial change in your financial situation, e.g. if you were to lose your job.

Make sure your emergency fund remains accessible if you get into an emergency.

</comment></comment></comment><comment><USER19> This whole hardcore quizzing and testing during interviews has to go. As far as I can see, all it does is create selection bias for people who memorize things or like to practice interview questions.

Maybe that's just me being too old for that kinda' crap.

<comment><USER20> I have been interviewing the last couple months and have the same opinion. I've been coding for years and have some pretty complex stuff up on my GitHub.

I quickly found out that nobody looks at your GitHub, maybe 10% max. didn't matter that I had code from two weeks ago that did complex segmented locking on a concurrent hashtable. still got asked "what is threading" level questions at every place.

After botching my first spate of interviews to stupid trivia I gave in and and read through a bunch of CSCI 100 course notes and "beginners guide to language x". My performance improved significantly.

Ironically the most useful tutorials were the most basic "write a string to a file", as I had forgotten the classes for opening raw files in my three languages of choice (since nobody in their right mind has any business using those classes in a well designed WebApp). Doesn't matter that I could look it up in 5 minutes, they want it on the whiteboard with no googling.

It's really easy to game such interviews as they require very little domain specific knowledge. If you say you know Cassandra or MVC, they'll just take your word for it... as long as you remember the classes for opening a raw file in r+w mode

<comment> steve-howard I'm not shocked that nobody looks at your GitHub. Reading other people's code takes time and energy that a lot of people aren't going to spend if they have a ton of candidates to sift through.

<comment><USER21> Yeah, but everyone says, "you need to have a GitHub. You're not serious about coding unless you have a GitHub. That's how you get jobs now."

<comment><USER22> This is the issue I see.

Every CodingHorror post and list of hiring tips demands a GitHub profile, with the implication that it had better contain useful, quality code. (And with a bit of a threat that you'd better not put any hacked-together, one-off project in there, even though everyone has some.)

That's good, I see the value of it, and I also understand why interviewers don't want to read it. But new devs have every right to be annoyed when the industry-standard wisdom says that you have to have a thing which is never used.

(The real answer is probably "New devs, get ready for the interview gamut. Experienced devs, call a contact and have a GitHub profile." But somehow that never comes up.)

</comment></comment></comment></comment></comment><comment><USER23> > A study by Triplebyte has found that bootcamp grads are weaker in these > areas than computer science grads.

Really?! Who'da thunk?

> At Hack Reactor, we're trained to mask our inexperience. In our personal > narratives, we purposely omit our bootcamp education.

Hm...

> Why? Otherwise, companies automatically categorize us into junior developer > roles or tag us as "not enough experience."

And you think that after a few weeks of bootcamp "education" you're anything but?

<comment><USER24> I mean, call it what you will, but a lot of these people are getting offers, man. Good ones. Which is more than I can say for myself with my comp sci degree and two years experience. Although my location is likely to blame for that.

<comment><USER25> More than I can say for my BS CS plus 17 years.

As I have had 7 different jobs for 12 different employers (due to mergers/acquisitions, by the most generous count), and have needed to run the entire interview gauntlet all 7 times, my primary career goal is no longer to earn more money. It is to never have to do another effing software-industry interview, ever again.

But damn. For $120k/year, in the region where I now live, I might just put Expo2 to whiteboard one more time.

I get tired of justifying my own existence to people who are only pretending to care that I am not actually a human-form automaton to crank out code. In short, the software-industry interview has always been _stupid_ , but it has also become increasingly _arrogant_ and _rude_. Is it really worth it to put up with the crap-on-you parade for a few more measly dollars in the paycheck?

<comment><USER26> > _" my primary career goal is no longer to earn more money. It is to never > have to do another effing software-industry interview, ever again.:_

I feel exactly the same way, even though the existence of those interviews is probably the main reason I was able to get into kinds of companies I did.

</comment></comment></comment></comment><comment><USER27> "At Hack Reactor, we're trained to mask our inexperience. In our personal narratives, we purposely omit our bootcamp education."

Assuming most people who do bootcamps are changing careers, how do you explain suddenly becoming a developer after years of another career?

<comment><USER28> also:

> companies automatically categorize us into junior developer roles

in other words, correctly categorized

<comment><USER29> This was the part I didn't understand at all. You go through a CS program for 4 years or more and end up as a junior developer and that's fine, but if you go through a 12 week coding bootcamp you're somehow more qualified and shouldn't be "benchmarked against junior developers"?

I do realize I'm making an assumption that there was no prior CS experience before the bootcamp, but isn't that the crowd they're targeting?

<comment><USER30> I think the boot camp grad is still going to be a junior developer _but_ I can kinda see where someone with a "vocational" (code camp) educated applicant might actually be more productive than a college educated applicant for certain jobs.

To use an imperfect analogy, who would be better at actually building houses; a vocational school grad (who built houses all day as part of his education) or a college educated architect? A lot of programming these days is "hammering nails" not architectural design.

<comment><USER29> True, but when I think of "junior" or "entry-level" anything I think of someone with no real world, on the job experience, and that applies to boot camp and college grads.

Boot camps might very well be better than college programs in terms of preparing someone to use development tools and methods as opposed to focusing on the theory behind them, but at the end of the day, you're still not doing "real" work where your choices have consequences in a boot camp as you would on the job.

Working constructively with other people in the field (including answering to and being able to discuss and defend projects with colleagues and superiors), completing projects within time or budget constraints, and being able to make your own informed decisions with regard to things like project scope, methods, and direction, with a proven history of success -- those are the skills that separate "junior" from whatever comes after that, at least in my opinion.

<comment><USER30> Oh, I agree. For one thing, Senior engineers have lots of failures under their belt. Another trait of Seniors is knowing when "good enough" is good enough for the task at hand vs. the "best" way they were taught in school.

</comment></comment></comment></comment></comment></comment><comment><USER31> I too went to a bootcamp and spent about 3 months searching for a job afterwards. I didn't study anything. I let my bootcamp knowledge get written to disk and freed up more room for new stuff. I drank a lot of beer and went hiking in the woods as much as I could. I worked on my projects ~5-7 days a week but never for 8 hours at a time. Just a constant, undirected exploration and work towards building new things. Granted, I had some background in tech (particularly in data science, stats, college-level programming) so I might be an edge case.

At first I thought I was screwed, but after 3 months I'd completed 3 vastly different projects and it showed in my interviews. I could speak intelligently about 5 or 6 different programming languages and a multitude of database technologies, libraries and had my college-years algo/OO knowledge in the background. I had done everything from front-end design to Machine Learning, low-level algorithms engineering to full scale apps. And then I got an awesome job. I doubled my yearly earnings. People may scoff at bootcamps, but it helped in my case - if nothing else I got half a year to mess around with computers instead of doing that after work like I had been for the last couple of years.

As far as interviewing goes: I got rejected a lot. I rejected a lot of companies, especially those who tried to sell themselves to me. I was picky about not working in a megapolis hell. I didn't bug people if they didn't get back to me. I turned down second interviews if the person who interviewed me was an asshole or was non-technical. And it all worked out.

Unsurprisingly, I landed at a company with a lot of views similar to mine. We all mock Silicon Valley. We don't work around the clock, we like having lives outside of work. Few of us are traditional tech people. All in all, a very life-affirming experience.

<comment><USER32> This is a really nice story! It made me smile. Thanks for sharing your experience.

</comment></comment><comment><USER33> Is anyone else bothered by the code at the beginning of this article? Simply returning the expression would have had the same effect, ie:

        function getDevJob(studying, hardWork, luck){
            return studying && hardWork && luck;
        }

I know that it might not make the code readable to novice javaScripters, but it bothers me anyway..

<comment><USER34> I'm more bothered because it's becoming "so clever" to put everyday life activities into a function. I saw code written in chalk on a sidewalk billboard at the door of a coffee shop yesterday. No, I will not reciprocate that cringe and verbally call a function to order my coffee because the barista learned Hello World the previous night.

<comment><USER35> Becoming? It's been this way since I first started hanging out in internet tech circles (eight years, longer I'm sure).

</comment></comment></comment><comment><USER36> I'm happy for this guy, and there are really good tips in here for managing an application funnel.

Like others, I'm surprised offers north of 110 are possible given his experience, and can't help but bristle a bit at him being a self described "full stack" developer when it appears he's a front end developer (does rails really count as being a backend engineer?).

But he worked exceptionally hard at the process (guessing having applied to 10x the places a typical engineering grad does?), and also has a strong background in business from a reputable university. For some jobs, especially at startups, knowing how to understand the business problem and deliver results can be really important. The challenge isn't the tech, it's combining just enough tech [1] with essentially being a product manager too.

[1] learning that "just enough tech" is not easy, and it's clear he worked hard to master a lot of material. It's just that many of us have been working that hard for many years and likely have more expertise / ability to learn new tech fast than can be gained by anyone in the course of a few months or a year; hence the initial surprise

<comment><USER37> Why doesn't rails count as a backend engineer? Would you also not count someone who works with Django as a backend engineer?

<comment><USER36> I would definitely distinguish between html / css / javascript and server side application code, be it in ruby or python, I just didn't think working on the server side application logic completed the "full stack".

To me full stack means you are into the systems a bit too and would be capable of setting up the stack itself (and perhaps enhancing it, or setting up custom batch systems), not just working effectively within a larger space provided by the application frameworks.

But perhaps I just have the terminology wrong? Full stack developer = someone who works across the application stack, and I'm thinking more of "systems" or "backend" engineer?

<comment><USER37> Yes, I do feel you have the terminology wrong. I consider myself full stack and I work with Rails, Django, etc. I have interviewed with many companies with the title "Full Stack Developer" and most of them have not expected the type of experience you are talking about. I think you are talking essentially about a Systems roles.

When you are full stack there's usually an assumption that you are "better" on one side of the stack and won't be strong at everything. So a back-end focused full stack developer would be better at the things you are talking about while a front-end focused full stack developer would be much stronger in Javascript / CSS. The main thing is that you understand how an app works end to end and can contribute / fix bugs across the stack.

<comment><USER36> Cool, thanks.

</comment></comment></comment></comment></comment><comment><USER32> well first thing - that code at the top can be simplified.

         function getDevJob(studying, hardwork, luck){
              return study && hardwork && luck;
         }

But more seriously - I actually really like point #2. I firmly believe that job interviews have a strong bias towards people with experience doing job interviews. Your "offer-ladder" seems to confirm that for me.

It reminds me of that freakonomics article about how real estate agents get more for their houses because they wait longer for a higher offer. By getting the practise and being better at job interviews and NOT jumping at the first offer, you get a better overall rate.

<comment><USER38> While we're at it, the function name `aTypicalDay` is one of the poorest naming choice I've seen in a while. Is it typical or atypical ?

<comment><USER39> In camel-casing, a capital letter indicates the start of a new word. Therefore this is clearly "a typical day" while "atypical day" would be "atypicalDay".

</comment></comment></comment><comment><USER40> > He told us to send emails directly to real people with each application. It > could be anybody. As long as someone read it.

> For most small companies or C-level executives, the email format is usually > firstname.lastname@example.com. For larger companies, it may be > email@example.com.

This advice is horribly annoying, and I really wish people would stop recommending this awful email guesswork garbage.

I'm an engineer, and I once had a [firstname]@[company].com email address at a company. Later on, the company hired a recruiter with same first name, followed by a head of marketing with same first name.

Naturally I started getting tons of unsolicited mail, several times per day, from people who simply assumed my email address corresponds to one of the other people with the same first name. This included a lot of resumes from people who graduated from coding bootcamp.

Often the same person would email repeatedly, a few days apart. It definitely did not help their chance of getting hired.

<comment><USER41> Horribly annoying to whom exactly? You? A person with a tech job who couldn't figure out how to create an email filter for the words "job" and "resume". OP increased his response rate almost 4x. Why wouldn't he recommend this practice?

<comment><USER40> Yes, annoying to me. It's unsolicited, unwanted email from a stranger, interrupting my concentration several times a day, and often not even intended to be sent to me. This is the very definition of spam -- why would you consider this an acceptable practice?

There's no fool-proof filter for this. I can't safely filter out all email containing certain keywords, even from external email domains. I would get legitimate email containing those words from external domains -- legit candidates, people I met at conferences, etc.

I don't argue that it's good to contact a real person when trying to get a job. But at least take the effort to ensure you're actually emailing the person you intend, not some other person who happens to have the same first name!

Given that the OP applied to _nearly three hundred companies_ , I can absolutely guarantee he just sent these out blindly based on guessing the first name. And seeing as he only got phone screens out of 11% of these companies, one would assume most recipients of these emails view them the same way I do: garbage.

<comment><USER41> Well then I suppose we agree. I'd never advocate mass emailing an unsolicited email without prior research. But, if I were looking for a job you better believe I'm gonna use this tactic, albeit in a calculated way (target 5-10 companies with very tailored emails and research on the recipient up front).

</comment></comment></comment></comment><comment><USER42> >> I applied to 291 companies, did 32 phone screens, 16 technical screens, 13 coding challenges, 11 on-sites, and received 8 offers.

How much time would that take?

Figure 15 minutes per company - 4,365 minutes, or 72 hours. And that's time just spent finding the company, changing around a cover letter, and then emailing it and responding etc.

32 phone screens? Let's say 30 minutes each, that's 960 minutes, or 16 hours of phone screens. Forget accounting for prep time, etc

16 technical screens, an hour or two, let's go 90 minutes. Again, not accounting for prep or anything else - 1440 minutes, or another 24 hours.

13 coding challenges. From experience companies want you spending no more than 1 day or 8 hours on a coding challenge, so 104 hours here.

11 on-sites. At least 2 hours each, 22 hours, not accounting for travel or anything like that.

Also, I would have targeted applications to a lot less than 291 companies. I guess if I was trying to get my first job I'd be a lot less picky, but the 'ideal' company to work at can be few and far between.

<comment><USER17> 15 minutes per company for applications is high. Organization helps a lot, and you can really optimize your workflow for sending out resumes.

Finding the company: approximate amount of time spent here is 5 seconds. You have a spreadsheet, just go to the next one on the list.

Changing the cover letter: template it with variables. Should end up being a single bash command, most of the time is locating and properly formatting company name, person of contact, and filling out a couple sentences about why you're interested. 90 seconds when you're in the flow of things, tops.

Replying to emails and the like properly counts as part of the organization for the phone and technical screens.

There's time costs for when the application process includes forms that take a bunch of time to fill out. Not because you finish ~20 minute applications, though, but a certain percentage of the ones you look at you wind up having to abort due to those barriers, so you amortize the cost in there.

If you can handle really boring repetitive work, and you're not doing much else that day, you can wind up sending out a hundred applications in a day without too much fuss. For scheduling phone screens, set up a Google Calendar and/or a youcanbook.me and let the other party pick a time that works for them. Prep for phone and technical screening has little marginal cost - <USER2> it'll be spending a few minutes grabbing notes on business models and tech stacks so you can look good, along with jotting down notes afterwards about follow-up and ideas to improve on.

On-site basically counts as a full day.

>Also, I would have targeted applications to a lot less than 291 companies. I guess if I was trying to get my first job I'd be a lot less picky, but the 'ideal' company to work at can be few and far between.

It's a numbers game. You want to look at as many as possible, so you can pick after you have information about them. Basically, it's probably easier to filter out companies based off of actually talking to people there, rather than going down the rabbit hole of figuring out your desiderata and researching how companies fit it.

tl;dr - the actual application process looks like it could've been done over 5 weeks, given prep work was complete. One week sending out a giant pile of applications, one week doing phone screens, technical screens, coding challenges, then just over two weeks of doing on-site interviews.

<comment><USER42> >> 15 minutes per company for applications is high.

Applications can be more than just sending out resumes. The worst is when you have to deal with some crappy web site, upload your resume, then fill out a bunch of web forms with your job history, take silly tests, fill out other pages of personal information...

<comment><USER17> Yeah. It was faster for me to abort when I noticed those and get an application in on the next company on the list instead. Amortized over all the companies on your spreadsheet, that winds up faster.

</comment></comment></comment></comment><comment><USER43> First: Good job on the author! I don't think I could make 300 application in a three months, and I am fortunate that I have never needed to. This is impressive determination and focus, and it paid off.

Second: Wow, programming is becoming a commodity. This is literally 1) Learn the latest trendy framework and nothing else, 2) Study to the test, 3) Interview well. Either the market will be flooded and salaries for generic JS devs will crash, or strong programmers need to find a way to differentiate themselves that cannot be copied by anyone in 2 months.

<comment><USER44> I'd argue that if strong programmers can't find a way to differentiate themselves from weak programmers in 2 months then yes, programming (from a hiring perspective) has become commoditized.

That being said, we're currently in a time where most of the "development talent" that we have actively employed are working on little more than glorified CRUD applications. The few that are working on more specialized tasks tend to be safer from such commoditization.

</comment></comment><comment><USER45> So whoever hired the guy should feel bad. He explains the strategy to boost his payroll, he was hiding the bootcamp he was attending and he was showing himself as experienced dev. And also why would you hire someone if 300 other companies were not interested in that person?

Ironically his lack of experience shows itself even in the first fancy function he writes on the blog post. Would not this unnecessary if block be a red flag in a coding interview?

I am sorry to see this type of people in the industry and I am sure I would do the best to not to let such people getting hired in my teams.

<comment><USER46> I always read that sort of if block as the mark of somebody who's been round the block a few times. Because they know that one day you'll want to place a breakpoint on one case or the other, and they know that one day they'll want to know what the value of the condition is before it's used, and one day they'll want to put some logging in, and so on - and they know they won't thank their old selves for making that harder.

This sort of hard-won experience is how you get the high salaries, you know...

<comment><USER47> While I agree it's often advantageous to set a local variable instead of just immediately returning an expression for breakpoint reasons, there's really no reason to have that if statement in there instead of just returning the local variable, and I think it reads poorly.

It's trivial to add the if statement if it's truly necessary in the future (like if you need to evaluate the variable beyond simply whether to return true or false).

</comment></comment></comment><comment><USER48> > Coming out of Hack Reactor, my weaknesses were data structures and > algorithms. ... > At Hack Reactor, we're trained to mask our inexperience. > In our personal narratives, we purposely omit our bootcamp education.

I fail to see how they prepared this student for a career in software development. Sounds like they get a Masters in technobabble.

<comment><USER49> I had the same thoughts. Programming is nothing BUT data structures and algorithms. Being weak in those two areas basically means you are weak at programming. He also talked about how he didn't like they immediately equated him to a junior dev when realizing he only had bootcamp experience. IMHO, a bootcamp is essentially like taking one elective at university on making web apps.

<comment><USER50> Understanding abstraction is more essential to programming than data structures and algorithms.

</comment></comment></comment><comment><USER51> 3 months of applying? Wow. Seems like whatever he got was well-earned to me. I really stick to projects too, but this is massive. I just don't have the time/patience for 3-months of searching while I am currently working.

Kind of makes me think that the market is selecting people who have someone else supporting them so they can do all this interview research. Seems backward in my opinion.

I keep hearing "interviewing is a skill too." Sure it is, but should it be? I mean, why are hiring managers looking for people who are good at pretending to know things rather than people who demonstrate real aptitude through getting things done?

<comment><USER52> Confidence is a proxy for competence, which, through the interview process, we are imperfectly testing.

<comment><USER53> >>Confidence is a proxy for competence

I take it you've never heard of Dunning-Kruger effect.

[https://en.wikipedia.org/wiki/Dunning–Kruger_effect](https://en.wikipedia.org/wiki/Dunning–Kruger_effect)

Or its opposite, Imposter Syndrome:

[https://en.wikipedia.org/wiki/Impostor_syndrome](https://en.wikipedia.org/wiki/Impostor_syndrome)

<comment><USER54> Just because there are exceptions, and we have names for both the positive and negative forms of the exceptions, doesn't mean there's not a strong correlation overall.

</comment></comment></comment></comment><comment><USER55> 3 months of boot camp and we call ourselves "engineers" (not this guy. I'm generalizing). I can't even begin to imagine what licensed engineers feel like when they read stuff like this.

<comment><USER44> It's a common thing in the field. My title was changed from Web Developer to User Experience Engineer, despite my groaning otherwise. Most junior developers enjoy the title inflation for a few months then start to realize it may have been conferred a loosely.

</comment></comment><comment><USER56> For some strange reason people hate recruiters, but during my most recent job search - a month ago - I worked with seven recruiting companies. I was submitted to 15 jobs after filtering for commuting distance, technology, salary requirements.

First noticed that I filtered based on salary. Most companies don't divulge salary ranges but recruiters know that up front.

Out of the 17: 2 - positions already filled before I started the process

1 - after further investigation, the technology stack didn't meet my requirements

1 - had qualification I didn't meet

10 - companies that wanted phone screens

8 - phone screens

3 - in person interviews

3 - <USER3>

All of this in only 2-3 weeks. There is some overlap and no company out of the 17 stopped the process (submitted -> phone screen -> in person -> offer). I either stopped the process after accepting an offer, the job req was put on hold, or the position was filled when the recruiter submitted it.

Two points. First, none of the submitted resumes disappeared into a black hole because I was using a recruiter. I knew my status for each job. The second point is that I'm no one special, I know plenty of developers that had the same experience.

Someone else asked how do you keep up with all of the applications - <USER4> spreadsheet.

<comment><USER47> How did you get one recruiter to submit you to 17 different positions? Any time I deal with a recruiter they seem to stop (or at least really slow down) trying to find you something until they hear a firm 'no' from whoever they submitted you to.

I think the most phone screens a single recruiter ever got me is two in a single week....maaaaybe three. And only one in-person interview at a time. It took a lot longer than 2-3 weeks to find the next job through them.

Also, they had many companies that were just plain old slow to schedule interviews. One in particular took two months to get around to scheduling an in-person, and I had found another job in the meantime.

<comment><USER57> I briefly worked as an accounting recruiter[1]. It's extremely plausible one person could be submitted to 17 different positions in a week, while another person gets one every other week.

Getting interviews is as much politics as it is being qualified. At the place I worked, recruiters owned their job listings and their applicants. You get paid more if you fill your jobs with your own applicants, for what I think are obvious reasons. Recruiters would only ask around for applicants if they didn't have anyone qualified for the role. So if the recruiter who interviewed you doesn't have a lot of job openings, and you are a pretty average candidate, you might not get sent out to a lot of companies, even if you are more qualified than other applicants.

On the other hand, if you have a candidate who has a great resume, you probably want to keep them for one of your own jobs as well. The candidates who got the most offers were generally candidates who had an uncommon background (and therefore would be difficult to place yourself) or who were liable to get hired before you could match them with one of your own openings. In that case you'd send an email to the other recruiters with a brief overview of the candidate (background, salary expectation, etc) and ask them if they had any openings for them.

In my experience, recruiters engaged in illegal hiring practices as well. For instance, if a company did/didn't want older individuals, you'd talk about whether they were interested in "seasoned" individuals (seasoned ostensibly being a reference to their experience) or set the experience required since college at [x] number of years, where [x] + 22 = the age of individual you were looking for. It was also well known which hiring managers wouldn't look at the resumes of women, or of individuals with "urban" names, etc.

Companies that were terrible places to work were always looking for "plodders" \-- people who spent a lot of time between switching roles (4 or more years). The expectation being that they would be less likely to quit. Other companies really want people who are "climbers" \-- people who tend to switch jobs or get a promotion every 18-36 months.

The candidates who got the most interviews were white males who went to a prestigious university, did internships, worked in a big-4 consulting firm for a few years, and then spent 1.5 - 3.5 years at each job after that point. They were referred to as "extremely presentable," in the sense that they almost always would interview well. Their recruiters would often send to interviews where the the hiring manager was asking for an amount below what the person was looking for though as a way of making the applicants available at a given salary look terrible in comparison. This would allow them to drive up the amount they were willing to spend and get some of the higher priced "average" candidates hired.

If you want a job, the best advice I have is to call/send emails to hiring managers at places you'd want to work, and ask them if they would be interested in a person with your background, or if they had any advice for you. Even good recruiters are mostly useful for negotiating salary (since the more money you make, the more they make), trimming the irrelevant parts out of your resume, and coaching you on how to do an interview. If you need help with the second and third points, you are probably better off paying for a career counselor, since they will have your best interests at heart. I suppose a recruiter might be a good choice if you have specific salary/benefits requirements and you aren't great at negotiating, though I've never really thought about that point since negotiation is probably my strongest skill.

[1] Recruiting accountants was the worst job I ever had. I knew nothing about accounting going in to it. Turns out I hate accounting, and talking to accountants all day was hell for me.

<comment><USER56> I'm a software developer and I haven't experienced any of those problems. My resume shows that I've been in the industry for at least 17 years and that's after taking my first job off of my resume. I graduated from an unremarkable state college, and I'm a minority.

When you're juggling 17 job opportunities knowing that you have a good shot at a least 10 offers, you really don't have to negotiate. Between the salary offers and the recruiters willingness to throw in a signing bonus, you can let the system work for you.

No matter how good you are negotiating, if the company has a budget of $90,000 and you are looking for $130,000, you can't square that circle and you won't know a lot of the time until after you've wasted time going through the process.

Also over the past 9 years I've had four jobs. I made a mistake and contacted a recruiter from the same company where I was already working with another recruiter and she told me that I was already working with one of her coworkers. Another recruiter mentioned their "morning meetings" where they all get together to share candidates and jobs. It's in the recruiters best interest to find a candidate a job even if they aren't the account manager for a specific company, knowing that a good developer can find a job in less than two weeks.

That being said, I've always been good at writing tech resumes and I am a good interviewer.

<comment><USER58> "I made a mistake and contacted a recruiter from the same company where I was already working with another recruiter"

That's not a mistake, or certainly not yours. You're not paying the recruiter, you're not they're client, and you definitely aren't beholden to them.

Sign an agreement to the contrary, that's different.

<comment><USER56> I wasn't referring to a mistake as far as ethically or legally, just that it seemed spammy on my part and useless to contact more than one recruiter at the same company when they share job openings and your first point of contact will usually split the commision with the owner of the account if they arent the owner.

</comment></comment></comment></comment></comment></comment><comment><USER59> Is it still a huge deal to have an encyclopedic knowledge of data structures and algorithms? This guy was applying for jobs doing React/Node, which is what I do, and two years after school I cant remember all the details of the sorting algorithms. Would it be so bad to tell the interviewer that if I do anything other than call browser APIs to sort data I am failing at my job and wasting time?

<comment><USER60> FWIW I've been doing this for over a decade and the number of times I've actually had to care about sort algorithms, balancing red black trees, or that other nonsense is basically only in interviews and only occasionally.

I say as much when people try to pull that stuff on me now. There's a copy of TAOCP on the shelf for a reason, if I need to know a good algorithm, Mr. Knuth's are certainly better than mine.

</comment></comment><comment><USER61> > _the most important thing you could be doing at any point is studying and > preparing._

"Most important"? Have fun with that. Life is too short to spend time memorizing the answers to over-the-top tech questions for some chance to work for a company no one has heard of (and isn't producing tech near the scale of interview knowledge they require).

<comment><USER62> One thing that I think is worth noting here -- this guy isn't from a university where he would have learned this, and likely hasn't spent a lot of time using or understanding data structures (unlike "the rest of us"). He's just out of a code camp, studying these sorts of things make sense in that situation. I'd hope someone more experienced wouldn't need to.

</comment></comment><comment><USER63> Great article.

The only part that I hesitated with was the part about getting through to real people.

After reading a post like this, not sure how hiring managers (or their team) are going to feel about getting inundated with emails from candidates. After all, that exact use case is why we have recruiting departments to begin with.

I would tweak it and say use your network to get in touch with real people. The effects of getting a million emails from candidates might be blunted a bit if they are coming from someone you actually know.

<comment><USER64> My sense is that it's just a good way to annoy people whose job isn't hiring. At best, you're risking annoying someone who is busy (and your email being deleted with no reply), at worst, you're actively penalizing yourself if you are demonstrating that you aren't willing to go through the standard hiring process that the company uses. (For other terrible ways that job applicants try to "stand out", Ask A Manager is a veritable goldmine[0]).

[0]: [http://www.askamanager.org/2013/06/a-job-applicant- stopped-b...](http://www.askamanager.org/2013/06/a-job-applicant-stopped-by- with-a-plant-and-candy.html)

<comment><USER65> The fact that his response rate when from < 5% for "applying the right way" to 22% for "maybe you upset a hiring manager" suggests his new approach, in spite of your reservations, is better for cases where you don't know anyone who can give you a warm introduction to a given company.

If anything, assuming most companies have an 'employee referral' program, emailing a random non-recruiter may have the additional advantage that, for no cost to you, someone at that company becomes incentivized for several thousand dollars to lobby for you.

<comment><USER66> It's very much a tragedy of the commons scenario, though: if one person emails a random within the company, they're going to stand out, maybe even get put in as a blind referral. If _everybody_ starts doing this, then it's just spam, and the emails are more likely to get dropped on the floor.

</comment></comment></comment></comment><comment><USER67> I just hate how these "bootcamps" are only in it for the money and then they have the audacity to tell their students to LIE on interviews. How about you actually pick a language YOU love, make projects, improve. Node.js LUL

<comment><USER68> That seems a little bit extreme, in my opinion. I'm writing the curriculum for a full-stack web developer bootcamp that we're launching in the early part of next year.

We're all "kind of" in it for the money. I have to support a full-time teacher salary for three months, administrative overhead, software/hardware licensing, curriculum development, and have enough left over to make it worthwhile to continue teaching these classes in the future. But we're all driven to fill a need that we see in the market (not enough engineers/devs available) and most of us perceive the shortcomings of traditional formal education and think we have an approach that can improve things.

As an example, I've been the lead engineer / director of engineering for the past five years and have realized that all of the junior engineers that we hire out of college generally take 2-4 months to get spun up on regular software development practices. We've got to teach them version control, team work habits, peer reviews, requirement solicitation, design document writing, etc. And all of those skills are on top of our industry-specific requirements.

I'd much rather hire someone that was passionate enough to pay for a bootcamp, wants to be an engineer, and has learned enough to start contributing fairly quickly.

And while we're going to be coaching our students on how to kick ass in interviews, we're certainly not going to advocate lying. We're going to focus on confidence, proper responses for things they don't already know about, and even get in to the "submitting your resume" process.

Don't be so cynical. Computers have only been an integral part of everyone's lives for the past 15 years or so. The entire world is trying to figure out how to train people how to be productive members of a post-labor society.

<comment><USER69> Which university doesn't teach version control, requirement solicitation and design document writing in a Software Engineering class or similar?

<comment><USER68> Shit, dang near all of them. Lol. Admittedly, most of my hiring experience with recent grads came out of smaller regional universities (Augusta University, Augusta Tech, Georgia Tech) and a few for-profit schools (Kaplan, Phoenix, Full Sail).

</comment></comment></comment></comment><comment><USER70> At least only 2.8 percent of the companies he contacted were interested in hiring someone whose only genuine reason to be interested in software development is the salary. Now I remember why I've gravitated towards sysadmin rather than dev, and avoid the big tech companies and their cult of overpaid mediocrity.

<comment><USER41> How did you infer from his post that his only genuine reason for becoming a developer was due to salary?

<comment><USER70> It is just an inference, for sure, but I reread the post, less angry, and imagining the author was a student I respected; It still comes off a bit crass, especially these two quotes:

"A less-talked about part of the bootcamper's journey is what happens after you graduate — when you're searching for that six-figure developer position."

"As I got more experience, I effectively "leveled up." I became capable of completing interviews at companies with higher hiring bars. This is illustrated below as a linear correlation between the number of weeks I was into the process and the base salary I was offered."

At the same time, if I imagine the author as a (highly organized) co-worker, seeking a better salary, I have a bit more respect for the legwork he has put in (although it is highly unlikely anyone with a full time gig would have the time for it).

It remains unclear whether salary was the author's _only_ reason to become a developer; there is only the absence of counterevidence. I would definitely feel uncomfortable hiring or working with a junior employee who attempts to "mask (their) inexperience", even during the hiring process.

</comment></comment></comment><comment><USER71> TL;DR: The barchart can be misleading. Increasing # of applications can decrease the rate at which they mature into offers.

I like some of your points like get through to real people. That's an incredibly important part of landing a job. However I do have an issue with the graphic at the beginning. I think it's misleading, because you shouldn't really be applying to 200+ companies. When you take that kind of approach its like you're selling yourself short (not putting your best foot forward). Its like saying "I'll take anything, just please give me a job". It's also more difficult to actually show interest in whatever company you're talking to, which is a key part of performing well and ultimately obtaining an offer. So you end up showing 8 offers from 291 applications, but I would argue that by making so many applications, you are decreasing the rate at which the applications turn into offers. I can offer a contrasting viewpoint to this job search thing. When I was in school for Physics I taught myself how to program and started focusing on Web Dev. I ended up dropping out of school and decided to become a programmer. In that initial job search I applied to three companies in SF. (Companies that I was familiar with and legitimately interested in) and got offers from all three. That was two years ago and I've since applied to two other companies in Mountain View (I'm trying to move to an ML engineer position) and received offers from both as well. And like I said I think the difference between what our bar graphs would look like is due to the fact that my applications were much more targeted and my interest and motivation in the companies was much more apparent.

<comment><USER72> What was your strategy for dealing with how most ML positions require advanced degrees?

<comment><USER71> So I was realistic about the companies I could apply to with no PhD/Masters (No Facebook AI Research for me). I also made sure I could have some sort of tangible projects completed. (Created a GAN to generate images of street signs, DL to predict steering angle for a car based on video feed, etc) Then I went around to meetups, workshops, conferences to meet people and learn. Then through talking to people in person I found some smaller companies that are implementing ML in interesting ways (self driving cars, building recommender systems) and applied to the two that I felt strongest about. The key though is that I met people from the company and talked to them about what they're working on and what I've been working on and if there's overlap, it shows that I can contribute to what they're working on. Every position has a requirement of some sort of degree, but I just ignore that and apply anyway if I've already met and talked to people at the company.

<comment><USER72> Good tips, thank you. I started in algorithmic trading with Java and Entprise-y stuff. Got bored and moved to front-end. Now looking to move to ML. Like you, no degree, but I apply anyway as long as I feel I have the right signaling.

</comment></comment></comment></comment><comment><USER73> How do people justify and act going into an interview if you think there is a less than 10% chance of you wanting the job.

Do you just walk in and say "Yeah, I don't think this is going to work but I came here just for the hell and experience of it." This feels like a shitty thing to do, it feels even more shitty to walk in like you really want the job when you're mostly there for the practice.

<comment><USER74> As companies commonly pay for your ticket if you have to travel to a job interview, a friend of mine half-jokingly suggested you could do it full-time as a job for a few years after university. You'd schedule several interviews in a far away city and charge that ticket several times.

More seriously, most people are scared of changing jobs and hate the application process, to their own peril. If you could really own this whole process you'd win on every level.

</comment></comment><comment><USER75> As someone who has gone through software engineer interviews with top Silicon Valley companies, what I see is that the process is biased towards 1) people with lots of time and good memory (so that you just work for several months to churn through the books/questions available out there), 2) new hires (tend to get easier questions as far as I can see, they don't get design questions, etc.) 3) people with competitive programming experience (especially Google or FB). If you are not in one of these groups then good luck, you will need that. Especially experienced software engineers who are married/have kids have very little time to prepare for these sort of interviews, which makes it very hard for them to succeed. The way software engineers are interviewed right now are totally messed up, and is a big waste of time.

</comment><comment><USER76> not sure how much trust to put into data from freecodecamp.com a company that despite it's name, seems to sell codingcamp products.

<comment><USER77> Source? I thought that they were all open curriculum and didn't even have a paid program.

It's been a while since I looked at it, but I've recommended it to people as one of the better sources of _actually_ free content, and not just upsells, and would like to know if that's not the case anymore.

</comment></comment><comment><USER78> Honestly, isn't that an unimaginably huge investment of time and effort? Wouldn't it be easier and cheaper, more educational, and maybe faster to just create a startup and get aquihired? I'm not in the market now, but that's my plan for the next time I'm looking. Its kind of a level up from merely registering an account at github.

I'd be dealing with business acquisition people instead of a role-mailbox in HR that's piped to /dev/null anyway.

I don't really want to move to CA and certainly can't afford it without a huge hit in the standard of living. However... if someone bought goofy-idea-by- vlm.com for two or three million bucks and an aquihire job in CA, then I still don't want to move there, but at least I could afford it if I absolutely had to.

<comment><USER37> No it's definitely not easier to build a company that exits (even an acquire) than it is to get a job at a tech company that pays 100K.

</comment></comment><comment><USER79> > At Hack Reactor, we're trained to mask our inexperience [...] > [...] > Ultimately, you need to convince companies that you can do the job. > > [...]At the same time, you need to convince yourself that you can do the > job.

Err.. Ultimately you need to be able to DO the job...

</comment><comment><USER80> Jesus Christ. To think I had to go to college for 4 years to get my CS degree, at the same time be an intern, take part in GSoC, and then work as a backend engineer for ~3 years only to make 1/66 what this guy is making in another part of the world.

:|

<comment><USER81> Where are you making ~$1.8k/year?

</comment></comment><comment><USER82> Speaking from a hiring manager's perspective:

I don't care if you're from a dev bootcamp or an Ivy League school. I care if you care about your craft.

Experience is really hard to quantify, hence the programming tests. They are a crude way to standardized the measurements.

But care for your craft comes through right away. I'd ask them about the stuff they are interested in within their domain, then dig a little deeper to see if they have a strong grasp of what they are talking about. Sometimes I'd debate with them.

I also find that the best engineers I've ever met came from a variety of countries. They turned out to be amazing team members to work with as well. Once you're no longer just looking at US schools and US dev bootcamps, you get amazing selection.

Speaking from an applicant's perspective:

Heck yea, study up no matter how trivial you think it is or how it belittles your years of experience. Remember that this crude method is not an accurate measure of the hiring company's potential or yours. It's just a filtering mechanism for both sides to start a dialog.

</comment><comment><USER83> Wow, instead, get 100% response rate from only the 5 jobs one should really apply for because they have a personal story to tell that is a great match for the work being asked. I've done that twice. Throwing your name against the wall results in a whole lot of wasted time. You got some offers, great, but next time be picky!

<comment><USER44> You can typically afford to be picky (or have jobs apply to you) once you have a notch in your belt.

</comment></comment><comment><USER84> I live in what should be considered a developed country in Europe with 5 years work exp also abroad, of which almost 2 of software development in a highly specialized field, and I make one third (1/3) of what the average CS grad makes in SF. It feels very bad...

<comment><USER74> How much you pay for rent, and how long is your commute? Maybe you feel a little better now :)

<comment><USER84> I live in my own house and my commute is 20 mins by car, but I still feel bad... thanks for the different point of view though

<comment><USER85> You live in your own house? That sounds much nicer than being out here in SF.

</comment></comment></comment></comment><comment><USER86> > Early on, I gained experience, built confidence, and secured offers from > companies that had less intensive interviews.

I hate being used for interview practice. Don't apply to work for me unless you're intending to accept an offer.

<comment><USER87> If the candidate is good I will take the opportunity to convince them otherwise.

</comment></comment><comment><USER12> How do you even manage this amount of information? A notebook can help but once you hit the 20 applications mark, it's impossible to know to which companies you applied for.

<comment><USER88> I'm not the author, but I went through a similar process looking for a job when I moved to a new city. I had ~120 applications over the course of a month, with a surprisingly similar funnel at each step.

Managing the process wasn't too hard. I simply kept a spreadsheet updated with contacts as rows, and columns with dates for every step of the process including first contact, second contact, phone interview (s), coding challenges, on-site interviews.

However, you're right when you say "once you hit the 20 applications mark, it's impossible to know to which companies you applied for." Early on in my application process, I wasn't applying to nearly enough places, because I wanted to hear back from someone before moving on to the next. A good friend of mine gave me the advice "You should be reaching out to so many people, that when you get a response, you'll need to go back to research who it was from." It's a weird mode to operate in, but once you realize that as a new-ish dev the process of getting a job is very much a funnel like the one in this post, it's a strategy that makes a lot of sense.

I would highly recommend anyone looking for a job to follow the advice in this article, it matches very closely with my experience. Especially resonant were the points about making contact with real humans, and also to push tons of companies into the pipeline.

</comment></comment><comment><USER89> I wonder how much Live Coding he had to do. I've been interviewing like crazy lately, and I've learned I hate live coding, and "thinking out loud". You're in a room with your laptop hooked up to the monitor, and 2 people are watching you code. Any small typing mistake or mouse movements can be a negative on your review. Live coding should die.

<comment><USER90> I disagree. Companies need to know these people can walk the walk. Sure, I don't expect you to know all the spec details. Googling the spec or asking questions is fine. I had one interviewee that went through a similar boot camp. The discussion portion of the interview went exceptionally well; he knew all the topics and had opinions on using certain technologies over others. It seemed like a good fit, until we got him in front of code. He struggled to do a simple object assignment in JavaScript.

To your point, any small typing mistake or mouse movements shouldn't be judged. Interviewers know you will be nervous during the interview. If they are discrediting candidates over that, they shouldn't be interviewing.

<comment><USER89> Define the object assignment? Was it really just an assignment statement?

I was rejected with almost no feedback from a company this month. I feel I solved their live coding thing correctly using a recursive approach. However, I was told they didn't like my coding style, so they didn't move me forward. They also said I moved the mouse too much.

<comment><USER90> The structure has the test pre-written and the actual code empty for the interviewee to fill in. As simple as setting person.name = 'Jeff', a trivial test to anyone with even basic JavaScript experience. I'm sorry about your poor experience interviewing. Barring a lack of understanding of any styles, coding style should not matter, that's what linting rules are for. Hopefully future companies you interview with will have a more reasonable interviewing process.

</comment></comment></comment></comment><comment><USER91> This reminded me of that scene from "The Big Short":

Mark Baum: I don't get it. Why are they confessing? Danny Moses: They're not confessing. Porter Collins: They're bragging.

</comment><comment><USER92> Ugh, the code in the teaser image. Triggers my OCD.

</comment><comment><USER93> Would love to interview you for Simple Programmer, YouTube and podcast: [http://YouTube.com/simpleprogrammer](http://YouTube.com/simpleprogrammer)</comment>