You could be direct with the coworker and call them out on their ulterior motive to pad their resume, but if you've misjudged their motive you'll look silly. If being direct is not an option, attempts to dissuade the coworker from using shiny tech overall won't work. Two suggestions --
* A more granular pushback is needed, for instance, "we shouldn't be using package X because it's not MIT license" or "the package has a higher memory footprint for what we need, have you tried package Y instead."Document these pushback arguments into a checklist to ensure your coworker has checked off before using new shiny tech.
* Convince others rather than your coworker of arguments against using shiny packages, articulated in terms of delay, extra cost, problems down the road, etc. It's an indirect approach but you won't be alone in pushing back on the coworker's scheme.
You're absolutely right, the environment ('market') matters as much as what you bring to the table ('product'). I've been in similar situations before where I've gone from being highly regarded by one manager to being regarded as average by the next manager. In a situation like this, it's best to change teams. While scouting for a team, pick one that gets a lot of attention from company leadership as they tend to focus their attention on teams with growth prospects. A team with growth will have more room for you to shine.
During coding interviews, I'm looking for the following evidence in a candidate:
1. how good is the candidate at problem solving?
2. is the candidate able to think in code?
3. are there any glaring syntax errors?
To assess the above three, a whiteboard, paper or Google Docs is sufficient. I'm not averse to using an IDE, just that the IDE's syntax checking hints will shift the candidate's focus to writing syntactically accurate code (#3) rather than on the problem (#1 and #2).
If all the interviewers were like that I'd be OK with using whatever they want. But one time I was doing a Python exercise on a google doc and I was missing a colon after an if statement. The guy had me for a couple of minutes trying to find my "error" without telling me it was syntax. The algorithm was correct.
The other problem I see is when you don't agree on something with the interviewer. One guy made me write some fictitious SQL queries on a doc and then asked me some questions. He was wrong about several things but we didn't have any way to test it. I was so shocked he didn't know that stuff that I had to tested after to see if I was actually wrong, but no.
I have a software startup and was in SS in 2017 with an assigned mentor and a second time in 2018 but without an assigned mentor. The 2017 SS experience was a lot better because of two things: 1. My cohort of startups was quite involved in meetings and forum discussions 2. our mentor has an agenda for weekly group meetings and gave every group a chance to talk about their progress. It comes down to these two things -- cohort and mentor -- and YC picks them for you, so YMMV.
Try video for leadership updates - it's more personal than written communication so helps build trust and you can explain things clearly with emphasis.
Couple ways you could do it: 1. a webcam recording of yourself, using quicktime (only on mac) or similar webcam recording tool 2. a screen recording where you talk through a slide deck of news, roadmap, etc. Again, using quicktime or chrome extensions such as the one I built: https://outklip.com. Outklip's advantage is you can record webcam along with screen, annotate during recording, do post-editing and upload to YouTube with a click.
I interiewed Sid Sijbrandij, the GitLab CEO (GitLab has 500+ members and is all remote) on running a distributed company. He said this about alignment: "I think it’s really important to write things down. People are very efficient at reading things. So, if you wrote it down you can refer to it, so you don’t have to say everything again, you can just drop a link. So, we write down a lot, in our handbook, on our OKRs page, you’ll find all our goals and strategy, etc. And at some point you keep repeating that, keep dropping those links and you keep answering questions. So, repetition is still needed, repetition is easier if you have one writeup and most people have already found it even during onboarding.". Interview video and notes here: https://outklip.com/blog/gitlab-building-a-distributed-compa...
Interesting point but it's unnecessary and irrelevant to compare startup scaling to hunting animals. Why hunt? As though we hunt customers. And why animals? Who in their right mind would hunt any of these animals. Could use a better analogy to communicate the point. Startup scaling is an act of persuasion rather than condescension.
Assuming the startup has a product, your questions should center on impact and growth.
1. Impact: What problem are they solving for users? How are users using the product?
2. Growth: How quickly are they growing users, both free and paying? How are they acquiring users?
If the startup has a convincing answer for 1, they're working on something concrete. If they don't have convincing answer, probe deeper to find out if they have tangible plans for what they're going to create.
If they answer question 1 well, ask them 2. If they're growing users quickly (for instance, double digit % week over week), the startup is totally worth considering. If they're not growing quickly, ask them how they plan to grow. It's useful to know how they're acquiring users -- if they're spending money to get users, you should ask if it's scalable. If they're getting users without spending much money, great.
Growth can fix most problems in a startup -- it attracts users, investors and talent. If they aren't seeing growth, they should at least have a tangible impact with the users they have and plans for growth.
Double digit week over week week is only possible for very early stage startups. 10% week over week for a year is 142x yearly, which just isn't sustainable for more than a year or two at the absolute maximum.
The 'you know' is a filler we use for traffic regulation. We use these fillers subconsciously to take micro breaks while speaking, to verbalize our thoughts and to indicate to the listener not to interrupt as we aren't done speaking yet.
Polish of delivery is just a nice to have feature, substance matters most of all.
I've attended public speaking courses, which tend to emphasize polish, but seeing some of the most effective speakers using fillers like 'ums' 'ahs' and 'you know' just goes to show polish doesn't matter all that much. Reality supersedes theory.
* A more granular pushback is needed, for instance, "we shouldn't be using package X because it's not MIT license" or "the package has a higher memory footprint for what we need, have you tried package Y instead."Document these pushback arguments into a checklist to ensure your coworker has checked off before using new shiny tech.
* Convince others rather than your coworker of arguments against using shiny packages, articulated in terms of delay, extra cost, problems down the road, etc. It's an indirect approach but you won't be alone in pushing back on the coworker's scheme.