There's no one thing that's going to be the line which, after crossing, you can safely stop calling yourself junior. Indeed, I've worked with many "senior" deve

There's no one thing that's going to be the line which, after crossing, you can safely stop calling yourself junior. Indeed, I've worked with many "senior" developers who I would have considered junior outside their area(s) of expertise (and I myself fall into this category as well!) When I'm conducting interviews and looking for hints that someone might be on the verge of "levelling up", I look for qualities that indicate someone has stopped following a preset path and is instead able to do their own pathfinding. That is, given a direction and a general set of guidelines, how deep are they able to go in order to solve this problem? If I tell you, "Hey, we want to add file uploads to this UI" in a Ruby project, do you: A) immediately go searching for a gem to handle this? B) Look for an AWS interface gem? C) Look at S3's HTTP docs and write their own class for handling? D) Stop and ask if we want to host the files ourselves or using a storage API of some sort? Each of those may be the right answer. A is what I would expect a junior (and likely most others) to do, and its a defensible choice in that file uploads are likely not interesting enough to spend much time on. B) is what I would expect from someone who knows that storage to S3 is pretty easy in most libraries, and therefore it may not be worth the dependency of something like Carrierwave, electing instead to write a thin wrapper around the interface (and whether they use it directly in application code, or write the wrapper, is an excellent way to discern whether they're just below or just above the line between junior and mid-level). If they're coming from a different platform background though, they might just be unaware of something like Carrierwave/Dragonfly/etc. Option C indicates that they're probably pretty comfortable getting deep into a problem, though perhaps not always making the best choices about where to spend time (but you get a pass if this is an interview setting, its really hard to know as a candidate what the other side of the table is looking for.) Going with option D often indicates the confidence to push back on requirements and make sure you're writing the right code, not just what the ticket or client asks for. The thing is, none of those in isolation is going to definitely indicate that someone is a junior or more advanced. They're all just pieces of evidence and have to be taken with other points of evidence to determine the answer to that question. Other things I'd probably try to focus on if I were trying to level up: * Know your tools. I don't care whether you use vi/vim, emacs, spacemacs, Sublime, atom, intellij or one of its brethren, or even textmate—know how to use it effectively to navigate your project and handle your top ten tasks like finding the implementation of a class or running your tests. * Know your CLI. I don't care that you know every flag to every possible command in the terminal. but realize that an IDE is usually just a layer over a lot of CLI tools that you should be able to handle in their native environment. * know how to read a stack trace effectively to find the root cause of an error quickly. * get good with taking constructive criticism. Humility is an important attribute in any team member. * Don't fall into the trap of thinking you know one tenth of what you believe you do. Don't think in absolutes, and don't argue with every potentially incorrect statement someone makes. * ask questions more than make statements. Whether its "Can you help me understand why you do that this way?" or "Why is the customer asking for this feature?" it will serve you well throughout your career.