How is a senior developer different from a junior developer?

There is not one right answer. It’s easy to say “a senior dev knows more and does more”, but I think there’s an additional dimension – a junior dev is merely expected to code to the spec, whereas a senior dev fundamentally takes responsibility and ownership for improving everything they encounter.

Here’s a braindump; obviously my opinion. Not a complete list, and not a one-size fits all. I was light on the exact technical requirements (as that changes), and focused more on the concepts. Perhaps in another blog post I’ll do a braindump of what a senior dev is not  (i.e. how is a senior dev different than a tech lead or architect). I’m using C# and .Net as an example, but you could easily substitute those.

There’s also an interesting matrix here.

Writes good code that just works

·         Be able to code to specification is assumed. Should be able to leverage experience and past domain knowledge to fill in some gaps in a spec. Does not need everything explained in complete detail.

·         Writes working code that handles non-happy path and has low bug count. Can quickly create code – does not need to continually refer to reference documentation.

·         Codes for non-functional requirements, like performance, maintenance, testability, security, etc…

·         Can write code with the minimal length and complexity.

·         Thoroughly unit tests applicable code.

Respected by peers

·         Has written a module or tool directly used by others on the team. A senior dev does not just write code in their corner.

·         Can review other’s code and suggest improvements that others will actually implement.

·         Other developers ask for your technical opinion

Experience

·         Has built end-to-end products, through all tiers, that ran in production for multiple  releases

·         Has written 10,000+ lines of C# code that passed code review

·         Has created at least 4 different Visual Studio project types (WinForm, web, WinService, Console, etc…)

·         Has created developer tools and utilities besides just visual studio. I.e. has used a profiler or visual studio plug-in or code analyzer or code generator.

·         Has troubleshot a production security or performance error.

·         Has written multi-threaded backend code

·         Has at least 1 technical niche of expertise

Takes Responsibility

·         Does actions to make other developers better, such as writes reusable code, mentors, solves critical path problems, automates a previously manual task, etc...

·         No longer just focused on development, but helps improve the process of development.

·         Can refactor legacy code without a formal project

·         Can resolve unanticipated coding or validation problems without pulling in a more senior resource

·         Can pick up new technologies without formal training (may need formal training for an entirely new platform)

·         Continually looks for code reuse and ways to decrease technical debt.

·         Can tell management what the developer needs in order to be more productive

Has platform-specific knowledge

·         This is the standard list you’d see on a job description (“Knows threading, diagnostics, reflection, IO, etc…, Can explain 5 design patterns, etc…)

Yes-no questions that a non-technical recruiter can ask during an interview

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/yesno_questions_that_a_nontechnical_recruiter_can_ask_duri.htm]

When interviewing, many companies first filter developers through HR (such as for online resume screening or a phone call). The irony is that they want a technical star, but screen all candidates through non-technical HR folk. Sometimes people in such situations, pressed for time, resort to quick yes-no questions. The naive approach is to just ask "rate yourself on 1-10", or "do you have over X years experience?" While I think the best type of interview is one where technical people can ask technical questions (or even write pseudo-code on the whiteboard), not every developer gets that opportunity. So if for whatever reason, the recruiter is limited to only yes-no questions, consider these kind of questions:

1. Do you program in your spare time? --> programming in your spare time implies that you enjoy programming, which implies that you're motivated and good at it.
2. Do you have any Microsoft Certifications? --> implies basic Microsoft-specific education
3. Do you have an engineering or CS degree? --> implies a basic general education
4. Have you ever lead a team of over 3 people? --> implies basic leadership abilities.
5. Have you ever programmed an application over X thousand lines-of-code? --> big apps will provide scalability and process problems that small apps never will.
6. Are you an active member of any professional groups? --> implies motivation
7. Have you ever been published (magazine, online journal, book)? --> implies good communication
8. Do you have your own website or blog? --> implies personal motivation and innovation
9. Do you contribute to any open-source projects? --> implies hands-on coding and working with others
10. Since college, have you read more than three technical books? --> implies continual, pro-active education, as opposed to just re-actively reading scattered blog posts.

This is only a partial list, but you get the idea. Many developers can have "X years experience", yet never do a single thing on this list. This list focuses on what you have done, not how long you've sat in front of a computer.