I don't, but I also don't call myself a senior developer. I'm just a "developer", middle level. I don't have a CS degree and I'm not algorithm or software patterns expert. I do web development and don't have experience with stuff outside of Laravel/PHP/Node.js/RoR and a myriad of front end technology. And no experience with very large scale applications that have millions of users.

I say all this to make the point that I'm definitely not competitive with the type of people working at Google, but I have plenty enough experience making great sites from start to finish with a variety of tools.

Being Senior mostly has nothing to do with the technologies per se. Its about being responsible enough, mindful enough, communicative enough, thoughtful enough, and patient enough to lead large features/projects/directives. Its about seeing the potential problems/opportunities with something and speaking up.

I have seen interns who can behave like senior engineers because they know how to take responsibility, talk with non-technical people, and tackle tough problems with confidence etc.

I feel confident I have the maturity/mindset for all of that, but I don't have the technical experience or breadth to confidently say "We should use this tool for this purpose". My input for "How would you select the technology this project?" would be to evaluate the available skillsets of my coworkers and pick the most appropriate framework and libraries accordingly. This might mean making an API with Rails, a front end with React, and use Google's mapping API if it was some sort of mapping application. That's about the limit of my confidence in tech decision making.

How much should we be writing tests? How much should those tests cover? What type of tests? Should we use Agile/Waterfall/etc? Do we need code reviews? Pair programming? Continuous integration? What should the deployment be like? What's the most appropriate database to use for this? How can we help ensure absolute security? What can we do to shave milliseconds from load time? How would we make ____ more distributed to handle high peak loads?

Those are all things that seem pretty relevant to being senior, and I don't have answers for them based on personal experience.

>My input for "How would you select the technology this project?" would be to evaluate the available skillsets of my coworkers and pick the most appropriate framework and libraries accordingly. This might mean making an API with Rails, a front end with React, and use Google's mapping API if it was some sort of mapping application. That's about the limit of my confidence in tech decision making.

That's one hell of a good answer! Nice work!!

This is exactly the problem I have too. I get interview questions like "You have to design xyz system, such that junior devs can start building it. How would you do it?"

I find it very tough to answer them unless I have personally faced the problem or if I have read extensively about it.

Sometimes I think that startup experience doesn't prepare you for this kinda stuff. In the early stages, it's all about "Fuck it, just ship it." So design and all go out the window. This is what is happening in my current company too.

Break the problem into logical pieces. Delegate based on the devs strengths.

Many of the items you've listed here are more cultural than technical.

Confidently saying "we're going to use this because I'm senior and I know it's the right choice" is something that I see as rarely being successful. It has its time and place, but it ain't something that you should be doing often. You mention bringing the right coworkers into the decision-making process, which is the more appropriate move.

Now, of the items you mention not having an answer to, I can give you a definitive answer to a few: ;)

- Do you need CI? Yes if it's helping you manage your risk. Do you need it for your 4 line bash script? Probably not. For an application your team works on regularly? It's 2016; Set up a freakin' CI server.

- Absolute security? This doesn't exist. Manage your risk, and the risk to the business. See: http://scholar.harvard.edu/files/mickens/files/thisworldofou...

- Tests? Yes. As far as coverage and what type, again, manage your risk. Does decent unit-level coverage and a couple of end-to-end tests give your team the confidence they need to develop quality software at a rate acceptable to your team and the business?

- Do we need code reviews? Dealer's choice, but manage your risk. If you're getting heavy on tech debt, or there are big holes in team understanding, and you notice work is slowing down as a result, you haven't been managing your risk.

- Most appropriate database? Manage your risk. Have the conversations with the business that give you a framework for doing a meaningful evaluation.

- Shaving millis off of load times? What value does this represent to the business? There's a cost/benefit analysis that needs to be done to determine whether two weeks of work improving the response time by 10ms produces noticeable business value. Perhaps there's a way to shave 8ms off the response time which will only take one day. How much are 2ms worth to the business?

--

It's nice to have personal experience answering questions like the ones you bring up, but I would only say "nice to have". As the previous poster mentioned, senior is IMO about being communicative and thoughtful more than it is about being right all the time or having a lot of battle scars to show off.

I realize you were possibly asking these rhetorically, but let me answer these questions for the sake of trying to let you see through the eyes of someone who does feel "somewhat confident" in guiding large projects; because I believe you'll find that you may have more intuition for it than you realize, and that at least for me there's been no Magic(tm)

How much should we be writing tests? - How much do you need them? (Are you grinding out an MVP on very short notice, or setting down the foundation of a long running important project?) and if you need a more obvious signal, are you hurting from not having them?

How much should those tests cover? - See the above; but additionally (and tautologically), what parts of the code do you worry about tests covering?

What type of tests? -What type does your team feel comfortable with using and maintaining long term?

Should we use Agile/Waterfall/etc? - See the above, additionally consider if the context you're in (because the powers that be over you incurr a LOT of constraints) really encourages one of these.

Do we need code reviews? - See "how much should I be writing tests"

Pair programming? - Continue to cite the above, as well as "does it work for your team"

Continuous integration? - Is the overhead worth the benefits? (this is not a loaded question)

What should the deployment be like? - Easy, robust, hard to fuck up, easy to clean up.

I stopped here intentionally because your latter questions touch on technical decision making, to which I'd give unified advice: Get to know the space. Get to know your tools, then ask someone smarter than you :) Less glibly, someone else has almost always done what you intend to, if not many someone else's, and their experience is so fucking valuable I cannot emphasize it enough, this is also half the benefit of having a personal network. However, you need a mental model of the space to evaluate their learnings in your context, and that just takes playing in that space until you feel comfortable with it.

I really hope this doesn't come off as a preachy rant, my goal is to address your final sentence; to echo my original statement, that I believe you can apply the experience you've gained as a dev thus far to the questions you claim to have no experience for (and you go so far as to demonstrate this e.g. your rails example); and even in absence or presence of that, leveraging your team and peers is invaluable for making "less bad choices", and you're already doing that by asking here on HN. You're already walking the path you are aiming for.

Just asking those questions makes you more thoughtful than most senior developers. The next step is knowing that you don't need the perfect answer, just something good enough.

This is interesting: what defines 'entry level', 'junior' and 'senior'?

Those other skills do require technical knowledge to be able to do well.

My suggestion, branch out and learn some of the other tools, even if you have to do it in a non-professional environment. For building sites, you're competing with things like Site Slinger or various similar services. To be competitive in that kind of a market you'll need to have a different kind of value add (i.e. look like something more than a developer) to make your resume look more interesting. Some of it also depends on where you're looking for work and if you're looking for local or remote work. I had to jump cities to get a foot in the door (East Texas to Austin).

YMV and good luck!

Unfortunately despite being in a big city, it's one of the worst big cities for tech jobs in the country (hence low salary). And moving isn't an option for another 4 years. I apply mostly to remote jobs because of this and I am sure those are more competitive.

Do you have any examples of other tools that would be valuable? I honestly think I'd be pretty unhappy with iOS/Android development due to the nature of most companies that focus in that area, and I assume that'd probably be an option you'd recommend. I have an interest in security and penetration testing, but it's such a horrendously complicated and difficult expertise to attain and I have no realistic expectations I would ever get a good job doing that.

Working with C/C++ or other less-web focused technology is an option obviously, but agains no CS background and it just seems like such an uphill battle to learn what I need and then convince someone to hire me for it.

Having an interest in security is a huge win for you. Hiring people into that field is impossibly hard because there are a tiny number of people employed in that area (I came from that field and it's very hard to find people to hire). That doesn't mean you're guaranteed a job, but if you want to be in that field, seek the jobs out. They exist.

Can I email you some questions about the field? Mostly surrounding what I should aim for as a base knowledge level before I'm employable and which topics are best for that while coinciding with my interests.

The point is to let them make the decision that there is a poor fit. Be confident in your abilities and your capabilities.

>Laravel/PHP/Node.js/RoR

That's senior to most of the people posting the jobs. You passed junior with PHP.

It's more my lack of depth with any of those aside from maybe Laravel that I would feel dishonest calling myself senior. I've made CRUD apps until my eyes bleed, but not a whole lot else. I don't have a lot of experience writing tests. I don't really have any open source code to show employers, only past projects that I've made as a side project or for an employer. It's rare that I have to write anything original that isn't already covered by the existing conventions of whatever framework I'm using.

It just feels like a few years experience isn't "senior" when you look at the candidate market in general. I am probably well below the average numbers of years experience.

Stop over-analyzing this, and quit feeling "dishonest" calling yourself senior.

Just do it. Start referring to yourself and seeing yourself as a senior software engineer and the paycheck is likely to follow-- regardless of your technical merits or lack there of.

Far less qualified individuals than yourself successfully bill themselves as senior engineers or solutions consultants, and make several whole multiples of your pay doing so.

My two cents: you should apply for some senior developer positions. You should be honest about your skills, but also you should be confident and not sell yourself short. What's the worst that can happen? You are already not getting callbacks.