> Disclaimer, I'm a CTO.
That's not a disclaimer, it's.. a claim. It's not even a 'disclosure' (which is what people saying 'disclaimer' often mean) really, it's more like a 'source', or just.. remove the word?:
> I'm a CTO, here's how I evaluate [...]
Sorry, just bugs me.
I just thought that here the tone was more 'here's why I can give you a good answer' than 'I'm aware my answer may be biased'.
Basically, the three things that are conflated into 'disclosure' are (all 'for example'):
1. (Disclosure) I have a vested interest in this because I work at the company being discussed [but I really think everything's fine and this isn't an issue];
2. (Actual disclaimer) I left the companh being discussed years ago so I have no knowledge of this issue [but my opinion is..];
3. (Source/background/listen to me!) I work at the company being discussed [so I'll pass on your feedback]
For me this is more a 3 than a 1, because there's no 'but' I suppose is the simple way to put it. You disclose a relationship because it might put what you're saying in a different (worse) light; here it's just why it's worth listening to. (If they'd said 'Company X is the best for negotiating salary IMO', 'I am CTO there though' would be a good disclosure!)
How do you evaluate people? Given the following information, how would you determine someone's skillset?
- hobby projects on the same technology stack
- open-source contributions (library with 15,000 monthly downloads)
- hobby projects on a different technology stack
- hobby projects on a different technology stack that made it into production with thousands of users
- previous companies
1. Paper screening the candidate. Looking at resume to see if they have skills for the job on paper. If so go to Personality Screening.
2. Personality Screening is done by talking to them and seeing if there's a cultural fit and also throw in some programming questions or feature discussions to see how they think.
3. Technical Screening by way of pair programming on a problem set that is based on the position that should show a mix of skills, tracing bugs or implementing features. If Frontend, mostly JavaScript and a Frontend Framework like React if needed.
As far as your questions go, we put weight on hobby projects but just so that we can see their code writing and some logic up front. As an example, I have seen one candidate with a recent Ruby on Rails project that had all their spaces and newlines everywhere, and I'm not talking about spaces or tabs here, think one chunk of code has 2 spaces, next had 3, another had 5, just everywhere that made the code super hard to read together with the messy logic/abstractions, from this, I assumed that they are still junior. On the contrary, I've seen a candidate that has really good code on a similar Ruby on Rails hobby project that reflected well on their work.
* only 5 countries have nominal, effective minimum wage above $30k (Denmark, Iceland, Sweden, Norway, Switzerland)
* when accounting for Purchasing Power Parity no country has minimum wage allowing to buy more than $30k in US (obviously ignoring Argentina, as it data is not reliable)
Additionally earning $34,000 in 2012 made you into the richest 1 percent globally [2]. So we may guess that today $30k easily lands you in the richest 5 percent globally.
[1] https://en.wikipedia.org/wiki/List_of_countries_by_minimum_w...
[2] https://foreignpolicy.com/2012/02/27/were-all-the-1-percent/
Interestingly a couple of high-wage countries that come to mind don't have a minimum wage at all: Switzerland, Denmark, Sweden.
In most of the world you can hire a junior programmer for $30k.
Even in larger groups, I wouldn't be surprised if the CTO participated deeper than you might at first assume.
Here's how I evaluate this if I was evaluating you:
1. I already have a salary budget already allocated for this role based on industry average for position and location (but location _could_ be irrelevant depending on skill mostly).
2. I look at your skillset and put you at the bucket for the position where you are at: low-med-high
3. I make my offer based on my evaluation.
4. If you are "worth it", meaning in the high bucket, then I would go out of my way to give you a good offer, up to max of my budget or to match how much you are asking. Else, I would say the offer is where it stands and either you take it or don't.
But to answer your question, it doesn't hurt to push back as long as you are confident in your skills and know your value is worth more. That one you have to make up for yourself by evaluating yourself with peers and other factors.
Oh. And if you do push back, make sure to give a good reason why it is so. For example, if I happened to put you in the low bucket, I might have evaluated you wrong or the tests did not show much of your skill, then make sure to outline why you deserve that salary increase with good reason. As a quick example, if the industry average in where you are is $50,000 and you are offered $30,000 which is the starting for a junior, you can say that you've been developing for awhile with at least 5 years experience and that $50,000 would be a fair salary etc etc.