Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Munkeymon
Aug 14, 2003

Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.



All of the things csammis suggested are more likely than a company giving a third party more detail on why you were let go than you got in writing, let alone when you were verbally informed.

Adbot
ADBOT LOVES YOU

huhu
Feb 24, 2006
You're all probably right. I prodded the HR guy and he gave me the vaguest of answers of "being more complete in my explanations about things". Or something along those lines. That's why my mind ended up where it did. I'll take another crack at it and post later.

Edit: Unfortunately, I was let go. My mistake was spending my first few months focusing the majority of my time on getting up to speed with the code but not with other aspects like getting to know the team or organization. My takeaway was that the ramp up period is there for a reason and getting to know team members and the organization is just as important as contributing code.

Better?

huhu fucked around with this message at 22:48 on May 11, 2018

huhu
Feb 24, 2006

Shirec posted:

No no, it's for Intrepid (https://www.intrepid.io). Haha, I'm nowhere near experienced enough to even attempt one of the big guys.

I'm meeting with my friend on Tuesday. I'll let you know what I learn.

Love Stole the Day
Nov 4, 2012
Please give me free quality professional advice so I can be a baby about it and insult you

Vincent Valentine posted:

Negotiating feels especially weird for me because I grew up extremely broke in the swamps of Louisiana so my salary is already 20k more than everyone I have ever known.
Ditto. Everyone in my family worked at Wal-Mart, Mcdonald's, were enlisted military, or were in some factory assembly line.

NeekBerm posted:

Ugh, so I'm still stuck in freshly graduated limbo. I've gotten in the habit of asking why I was rejected, and a theme is starting to develop:
We're in the same boat, welcome to the club

Vincent Valentine
Feb 28, 2006

Murdertime

For you guys who have been struggling for awhile, try keeping track of everything. I know this is gonna sound like an absolute shitload of work, but it's really only in setup.

Post your resume and a cover letter template first, and your github if you feel comfortable with that. We can scrutinize each of these in turn and tell you if things need to be changed. This thread is usually pretty good about offering good suggestions.

Next, make a spreadsheet. It needs to have the following columns:

Job: A link to the job posting, an(relatively anonymized) email address of who you sent directly too if applicable, or some kind of information if you applied some other way. A very, very brief description of the job(i.e. "Senior Front-end web dev. 3yrs exp, degree requested"). If you are applying online to a job posting, include the date the job was posted.
Date: Date resume was submitted.
Rejected: You received a written or verbal clear rejection, an email(even a form letter) is a rejection. Calling to tell you they are not moving forward is a rejection. 30 days passing with no word after applying is not a rejection.
Phone screen: A phone screen is someone calling you to ask you basic information. "Do you know c++???" and not "Tell me how you'd implement a bubble sort"
Tech screen: A tech screen is someone doing very basic almost trivial test to make sure you're not just making poo poo up so they know whether or not it's worth ACTUALLY interviewing you. "Can you show me how you'd implement a search bar?"
In-Person interview: You're called in to really interview. Relatively self explanatory.
Second-Round interview: Same as above except you've clearly made an impression and now you need to dial it up a bit.
Offer received: Self-explanitory, include the salary offered. obviously not very important if you accept, but it's important to list this in case you decide to not take an offer.
Additional notes: Write down anything extra, like "Told to apply for job by guy at meet-up." or "Rejection cited lack of experience." or "Things seemed to go really well, but ultimately rejected."

Mark the date that you reached the point in each column. Leave it blank otherwise.

If you can make all these columns and mark down for each job, it will give us a very clear idea of where your weak points are. For example, if you're not progressing past the phone screen stage, it's very likely that you are just not making an impression over the phone, maybe you need to work on your "elevator pitch". If you're only getting a couple of interviews and they stop there, it might not have anything to do with skill and instead will likely have more to do with nerves because your interviews are so infrequent. A lot of flat-out rejections before even getting to phone screens(Remember, this doesn't mean they just ignore you for 30 days or more), means your resume likely needs work.

All these trends can help you(and us) identify where you need work. It helps you identify what you might be doing wrong, such as noticing you're only applying to jobs that require a very low amount of experience or do not list a degree requirement.

Every thirty days post your spreadsheet. We can take a look at trends and see what you should focus on over the following thirty days, and hopefully offer real, actual improvement where you really need it instead of just having you think you need to read Cracking the Coding Interview again.

Shirec
Jul 29, 2009

How to cock it up, Fig. I

huhu posted:

You're all probably right. I prodded the HR guy and he gave me the vaguest of answers of "being more complete in my explanations about things". Or something along those lines. That's why my mind ended up where it did. I'll take another crack at it and post later.

Edit: Unfortunately, I was let go. My mistake was spending my first few months focusing the majority of my time on getting up to speed with the code but not with other aspects like getting to know the team or organization. My takeaway was that the ramp up period is there for a reason and getting to know team members and the organization is just as important as contributing code.

Better?

Sorry for the incredibly late response, but this does seem a lot better. Perhaps some other folks have feedback on this, but I think it shows you clearly know what happened, you've learned from it, and are moving on. And it's not a terrible red flag either, more that they also dropped the ball as well (which is good, I think)

huhu
Feb 24, 2006
First company I used my response with invited me back to interview with the CTO. Sooo. Maybe not as bad as I'd thought.

Shirec
Jul 29, 2009

How to cock it up, Fig. I

huhu posted:

First company I used my response with invited me back to interview with the CTO. Sooo. Maybe not as bad as I'd thought.

The new one or the previous one? Did practicing it beforehand help? I hope it goes well!

putin is a cunt
Apr 5, 2007

BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

huhu posted:

First company I used my response with invited me back to interview with the CTO. Sooo. Maybe not as bad as I'd thought.

Well to be fair, the company you used the previous iteration with invited you back also and even offered you the job so there might be a bit of confirmation bias going on. I doubt very much that the original offer being rescinded had anything at all to do with this aspect of your interview.

Edgar Allan Pwned
Apr 4, 2011

Quoth the Raven "I love the power glove. It's so bad..."
So just double checking- I can put my resume here for improvements right? Do i just block out contact info?


also my company is currently hiring so Im worried if i update my resume they will eventually find it because I have experience in what theyre looking for. Is there a way to avoid this or handle them finding out im looking for something else?

Edgar Allan Pwned fucked around with this message at 19:33 on May 15, 2018

lifg
Dec 4, 2000
<this tag left blank>
Muldoon
Yes, post the resume.

Normally you don't need to be ultra-secretive about job hunting, most people just stick to not talking about it at work. If HR sees your resume online, they'll just ignore it. Savvy managers will notice you're using vacation time in half day increments mid-week, but they won't bring it up.

putin is a cunt
Apr 5, 2007

BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

Edgar Allan Pwned posted:

So just double checking- I can put my resume here for improvements right? Do i just block out contact info?


also my company is currently hiring so Im worried if i update my resume they will eventually find it because I have experience in what theyre looking for. Is there a way to avoid this or handle them finding out im looking for something else?

Where are you putting your resume, such that they might somehow chance across it?

Phraggah
Nov 11, 2011

A rocket fuel made of Doritos? Yeah, I could kind of see it.
Help I got an offer and don't know what to check or ask about. Initial thoughts: 1099/w2, retirement contributions, ???

The Fool
Oct 16, 2003


Without knowing anything about your experience, title, or region? Start at $450,000

Phraggah
Nov 11, 2011

A rocket fuel made of Doritos? Yeah, I could kind of see it.

The Fool posted:

Without knowing anything about your experience, title, or region? Start at $450,000

Sorry not talking about salary, but other stuff to watch out for.

Essentially, the offer letter versions of the interview questions.

lifg
Dec 4, 2000
<this tag left blank>
Muldoon

Phraggah posted:

Sorry not talking about salary, but other stuff to watch out for.

Essentially, the offer letter versions of the interview questions.

Normal things to ask about are benefit things like vacation days, sick days, WFH policies, flex hours.

kitten smoothie
Dec 29, 2001

Make sure to get a copy of the health insurance options. If the only option available to you is a high deductible plan, then use that as a lever for more money.

blorpy
Jan 5, 2005

The Fool posted:

Without knowing anything about your experience, title, or region? Start at $450,000

$420,069*

If they recognize the ref they are required to immediately give it to you

huhu
Feb 24, 2006

Phraggah posted:

Help I got an offer and don't know what to check or ask about. Initial thoughts: 1099/w2, retirement contributions, ???

Is it 1099? From what I've gathered from this thread, 1099 sucks and you need to ask for lots more money. $X in a full time offer is equal to $X*2 in 1099.

baquerd
Jul 2, 2007

by FactsAreUseless

huhu posted:

Is it 1099? From what I've gathered from this thread, 1099 sucks and you need to ask for lots more money. $X in a full time offer is equal to $X*2 in 1099.

On the other hand, 1099 can be awesome for the same reason when you do get x*2. It also gives you access to self employed retirement accounts that are better than most any 401k in terms of contributions allowed. It gives you total freedom in benefits. If you're billing hourly that can also be huge.

Just make sure the numbers work out!

Shirec
Jul 29, 2009

How to cock it up, Fig. I

Tomorrow I fly out, Tuesday I interview. I've been reviewing all the stuff listed on the Glassdoor interviews and general practice. If they ask me anything deep algorithm wise, I'll be screwed, but I'm hoping it'll be non terrible whiteboarding session.

Have me in your thoughts on Tuesday goons,

Jose Valasquez
Apr 8, 2005

Shirec posted:

Tomorrow I fly out, Tuesday I interview. I've been reviewing all the stuff listed on the Glassdoor interviews and general practice. If they ask me anything deep algorithm wise, I'll be screwed, but I'm hoping it'll be non terrible whiteboarding session.

Have me in your thoughts on Tuesday goons,

Good luck, you deserve to get out of that shithole

LLSix
Jan 20, 2010

The real power behind countless overlords

Shirec posted:

Tomorrow I fly out, Tuesday I interview. I've been reviewing all the stuff listed on the Glassdoor interviews and general practice. If they ask me anything deep algorithm wise, I'll be screwed, but I'm hoping it'll be non terrible whiteboarding session.

Have me in your thoughts on Tuesday goons,

Good luck!

ultrafilter
Aug 23, 2007

It's okay if you have any questions.


Shirec posted:

Tomorrow I fly out, Tuesday I interview. I've been reviewing all the stuff listed on the Glassdoor interviews and general practice. If they ask me anything deep algorithm wise, I'll be screwed, but I'm hoping it'll be non terrible whiteboarding session.

Have me in your thoughts on Tuesday goons,

Good luck!

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

Shirec posted:

Tomorrow I fly out, Tuesday I interview. I've been reviewing all the stuff listed on the Glassdoor interviews and general practice. If they ask me anything deep algorithm wise, I'll be screwed, but I'm hoping it'll be non terrible whiteboarding session.

Have me in your thoughts on Tuesday goons,

Have fun!

Knockknees
Dec 21, 2004

sprung out fully formed
I'm not a programmer.... can I ask about being a Project Manager for software development?

I used to be a PM in another industry, but my job was awful and I left it. Now I want to do something new. I've successfully made it through a few rounds of interviews at a small software development consultancy, and now they've asked me to do a week-long audition.

From the interview process so far, I get the impression that they like me and that my general client handling creds are fine, but that the audition might be because they aren't sure about my ability to pick up an understanding of the tech side of things, since I don't have a software background. I figure, it can only help to spend these two weeks before my audition building up some foundational knowledge. Here's what I know about them so far:

*I own and have read Cockburn's "Agile Software Development". I also know that they use some XP principles, and I've got that book too, but I haven't dived into it.
*I know that they focus on Rails, React, and Elixir

So like, I can google "what is Elixir", but here's what I'm hoping to understand before I go in:

What are the things that are most helpful for you as a developer to have the PM understand?
What are the smart questions I should be asking?
As an industry outsider, what are the things I don't realize that I don't know about working in software?

Job searching sucks and I've been looking for a while, so I really want to make sure this goes well!

New Yorp New Yorp
Jul 18, 2003

Only in Kenya.
Pillbug

Knockknees posted:

I'm not a programmer.... can I ask about being a Project Manager for software development?

I used to be a PM in another industry, but my job was awful and I left it. Now I want to do something new. I've successfully made it through a few rounds of interviews at a small software development consultancy, and now they've asked me to do a week-long audition.

From the interview process so far, I get the impression that they like me and that my general client handling creds are fine, but that the audition might be because they aren't sure about my ability to pick up an understanding of the tech side of things, since I don't have a software background. I figure, it can only help to spend these two weeks before my audition building up some foundational knowledge. Here's what I know about them so far:

*I own and have read Cockburn's "Agile Software Development". I also know that they use some XP principles, and I've got that book too, but I haven't dived into it.
*I know that they focus on Rails, React, and Elixir

So like, I can google "what is Elixir", but here's what I'm hoping to understand before I go in:

What are the things that are most helpful for you as a developer to have the PM understand?
What are the smart questions I should be asking?
As an industry outsider, what are the things I don't realize that I don't know about working in software?

Job searching sucks and I've been looking for a while, so I really want to make sure this goes well!

If they're hiring PMs, they're not doing Agile (or at least, not by-the-book Agile), so you can throw that book out. Agile teams have 3 roles: the scrum master, the product owner, and software developers. Are they trying to fill the role of product owner or the role of scrum master, or are they not actually Agile?

The most important thing you can understand is Conceptually simple does not mean the same thing as simple to implement. Do not make assumptions about complexity. Do not set arbitrary deadlines based on how simple it seems to you, because you, as a non-developer, are totally unqualified to accurately estimate software development projects.

Here's an easy example:
Customer says "we want to be able to rename Widgets in our Widget manager application".
You think, "Renaming something? That sounds easy."
The developers say, "Renaming widgets is going to take several months of work because..." followed by a laundry list of technical challenges.
(this is a real example that I saw in an application shipped by a major software vendor -- renaming widgets actually took several years to successfully implement because of some very poor technical decisions made about a decade prior)

Along those lines, familiarize yourself with the concept of "technical debt".

You may not realize that, in a 40 hour work week, a productive developer will get somewhere between 20 and 30 hours of programming done. The more senior and skilled the developer, the less time they get to program because they are more involved in meetings/architecture, mentoring, and putting out fires. This is why Agile teams go off of non-hour-based planning concepts like "story points" and "velocity" -- a day in developer time is not necessarily an 8 hour block of time, and something that takes me an hour might take someone else 5 hours.

You are not going to understand a lot of concepts or terminology that other people take for granted. That's okay. Ask for clarification or explanation as needed. Do not try to use terminology that you don't fully understand. To the extent that is possible, you should be working at the "user story" level, where things are being discussed in terms of functional requirements and business goals. Leave it to the technical people to figure out how to best achieve the goals.

New Yorp New Yorp fucked around with this message at 21:46 on May 21, 2018

Slimy Hog
Apr 22, 2008

New Yorp New Yorp posted:

If they're hiring PMs, they're not doing Agile (or at least, not by-the-book Agile), so you can throw that book out. Agile teams have 3 roles: the scrum master, the product owner, and software developers. Are they trying to fill the role of product owner or the role of scrum master, or are they not actually Agile?

The most important thing you can understand is Conceptually simple does not mean the same thing as simple to implement. Do not make assumptions about complexity. Do not set arbitrary deadlines based on how simple it seems to you, because you, as a non-developer, are totally unqualified to accurately estimate software development projects.

Here's an easy example:
Customer says "we want to be able to rename Widgets in our Widget manager application".
You think, "Renaming something? That sounds easy."
The developers say, "Renaming widgets is going to take several months of work because..." followed by a laundry list of technical challenges.
(this is a real example that I saw in an application shipped by a major software vendor -- renaming widgets actually took several years to successfully implement because of some very poor technical decisions made about a decade prior)

Along those lines, familiarize yourself with the concept of "technical debt".

You may not realize that, in a 40 hour work week, a productive developer will get somewhere between 20 and 30 hours of programming done. The more senior and skilled the developer, the less time they get to program because they are more involved in meetings/architecture, mentoring, and putting out fires. This is why Agile teams go off of non-hour-based planning concepts like "story points" and "velocity" -- a day in developer time is not necessarily an 8 hour block of time, and something that takes me an hour might take someone else 5 hours.

You are not going to understand a lot of concepts or terminology that other people take for granted. That's okay. Ask for clarification or explanation as needed. Do not try to use terminology that you don't fully understand. To the extent that is possible, you should be working at the "user story" level, where things are being discussed in terms of functional requirements and business goals. Leave it to the technical people to figure out how to best achieve the goals.

This is pretty drat good.

Portland Sucks
Dec 21, 2004
༼ 㤠◕_◕ ༽ã¤

New Yorp New Yorp posted:

If they're hiring PMs, they're not doing Agile (or at least, not by-the-book Agile), so you can throw that book out. Agile teams have 3 roles: the scrum master, the product owner, and software developers. Are they trying to fill the role of product owner or the role of scrum master, or are they not actually Agile?

The most important thing you can understand is Conceptually simple does not mean the same thing as simple to implement. Do not make assumptions about complexity. Do not set arbitrary deadlines based on how simple it seems to you, because you, as a non-developer, are totally unqualified to accurately estimate software development projects.

Here's an easy example:
Customer says "we want to be able to rename Widgets in our Widget manager application".
You think, "Renaming something? That sounds easy."
The developers say, "Renaming widgets is going to take several months of work because..." followed by a laundry list of technical challenges.
(this is a real example that I saw in an application shipped by a major software vendor -- renaming widgets actually took several years to successfully implement because of some very poor technical decisions made about a decade prior)

Along those lines, familiarize yourself with the concept of "technical debt".

You may not realize that, in a 40 hour work week, a productive developer will get somewhere between 20 and 30 hours of programming done. The more senior and skilled the developer, the less time they get to program because they are more involved in meetings/architecture, mentoring, and putting out fires. This is why Agile teams go off of non-hour-based planning concepts like "story points" and "velocity" -- a day in developer time is not necessarily an 8 hour block of time, and something that takes me an hour might take someone else 5 hours.

You are not going to understand a lot of concepts or terminology that other people take for granted. That's okay. Ask for clarification or explanation as needed. Do not try to use terminology that you don't fully understand. To the extent that is possible, you should be working at the "user story" level, where things are being discussed in terms of functional requirements and business goals. Leave it to the technical people to figure out how to best achieve the goals.

Knockknees
Dec 21, 2004

sprung out fully formed
Awesome, thank you! I'll definitely work on further familiarizing myself with the terms/concepts you mention.

New Yorp New Yorp posted:

If they're hiring PMs, they're not doing Agile (or at least, not by-the-book Agile), so you can throw that book out. Agile teams have 3 roles: the scrum master, the product owner, and software developers. Are they trying to fill the role of product owner or the role of scrum master, or are they not actually Agile?

Honest question: what do you mean by "actually Agile"? I had gotten the impression that Agile could mean a lot of different things, since the manifesto and principles are pretty broad and seem to leave a lot of room for adaptation. This chart that find myself referencing often (https://www.agilealliance.org/agile101/subway-map-to-agile-practices/) makes it seem like there's a lot of different ways to go about it. I know the company in question uses story carding and pair programming (when possible), but I haven't heard them use "scrum master" or "product owner". (Yet? The person interviewing thus far is Operations and seems a little disconnected from some of these details, but they said I'd learn more in the audition). They are a small company with small teams - so maybe roles have been adapted because of that.

Regardless of what its called, here's what I've learned about their process so far: They start with a story carding session to develop the user story and break the story down into features. Then, they provide regular frequent progress updates to clients, deliver incremental usable iterations of the software, and do as-you-go testing. The primary role they need me to play is to be a buffer for the developer from distractions, facilitate communication, help manage relationships (especially when clients get antsy), and generally help set the developers and designers up for success. I know that they also want me helping run the story carding process at the outset of the project (from what you said, I'm guessing this is to get me involved with the functional requirements/business goals from the beginning).

But what I'm hearing is that one of the things I'll need to get a better handle on is how they define their roles and process, whatever it is!

New Yorp New Yorp posted:

The most important thing you can understand is Conceptually simple does not mean the same thing as simple to implement. Do not make assumptions about complexity. Do not set arbitrary deadlines based on how simple it seems to you, because you, as a non-developer, are totally unqualified to accurately estimate software development projects.

Here's an easy example:
Customer says "we want to be able to rename Widgets in our Widget manager application".
You think, "Renaming something? That sounds easy."
The developers say, "Renaming widgets is going to take several months of work because..." followed by a laundry list of technical challenges.
(this is a real example that I saw in an application shipped by a major software vendor -- renaming widgets actually took several years to successfully implement because of some very poor technical decisions made about a decade prior)

Along those lines, familiarize yourself with the concept of "technical debt".

I get the impression that my next step in this scenario might be to help explain this to the customer. If the developers give me a technical laundry list, the challenge for me might be understanding it well enough to communicate the main thrust of the issue to the client without overwhelming them with details... and having them still feel like a partner in the process!

New Yorp New Yorp posted:

You may not realize that, in a 40 hour work week, a productive developer will get somewhere between 20 and 30 hours of programming done. The more senior and skilled the developer, the less time they get to program because they are more involved in meetings/architecture, mentoring, and putting out fires. This is why Agile teams go off of non-hour-based planning concepts like "story points" and "velocity" -- a day in developer time is not necessarily an 8 hour block of time, and something that takes me an hour might take someone else 5 hours.

You are not going to understand a lot of concepts or terminology that other people take for granted. That's okay. Ask for clarification or explanation as needed. Do not try to use terminology that you don't fully understand. To the extent that is possible, you should be working at the "user story" level, where things are being discussed in terms of functional requirements and business goals. Leave it to the technical people to figure out how to best achieve the goals.

This is really good perspective, thanks.

New Yorp New Yorp
Jul 18, 2003

Only in Kenya.
Pillbug

Knockknees posted:

Awesome, thank you! I'll definitely work on further familiarizing myself with the terms/concepts you mention.


Honest question: what do you mean by "actually Agile"? I had gotten the impression that Agile could mean a lot of different things, since the manifesto and principles are pretty broad and seem to leave a lot of room for adaptation. This chart that find myself referencing often (https://www.agilealliance.org/agile101/subway-map-to-agile-practices/) makes it seem like there's a lot of different ways to go about it. I know the company in question uses story carding and pair programming (when possible), but I haven't heard them use "scrum master" or "product owner". (Yet? The person interviewing thus far is Operations and seems a little disconnected from some of these details, but they said I'd learn more in the audition). They are a small company with small teams - so maybe roles have been adapted because of that.

Regardless of what its called, here's what I've learned about their process so far: They start with a story carding session to develop the user story and break the story down into features. Then, they provide regular frequent progress updates to clients, deliver incremental usable iterations of the software, and do as-you-go testing. The primary role they need me to play is to be a buffer for the developer from distractions, facilitate communication, help manage relationships (especially when clients get antsy), and generally help set the developers and designers up for success. I know that they also want me helping run the story carding process at the outset of the project (from what you said, I'm guessing this is to get me involved with the functional requirements/business goals from the beginning).

But what I'm hearing is that one of the things I'll need to get a better handle on is how they define their roles and process, whatever it is!

You have the main thrust right, and it sounds like they're doing Agile but with possibly some different terminology. To map the role you're describing to my understanding of Agile, it sounds like they're hiring a scrum master. The client is the product owner.

Knockknees posted:


I get the impression that my next step in this scenario might be to help explain this to the customer. If the developers give me a technical laundry list, the challenge for me might be understanding it well enough to communicate the main thrust of the issue to the client without overwhelming them with details... and having them still feel like a partner in the process!

The key is to understand who's going to be on the call and what the scope is. If it's going to be a highly technical call, you need someone technical on your end to jump in. Some of us love doing that kind of thing.

The earlier you get technical folks involved, the better -- even if it's just to listen in, take notes, and discuss their thoughts with you after the call. You'll probably discover that having someone who can ask some clarifying questions will be a great help when it comes time to start estimating, and sometimes those "clarifying questions" make client requests magically disappear as the client discovers that they don't actually know what they want or that the thing they want already exists.

Xerophyte
Mar 17, 2008

This space intentionally left blank

New Yorp New Yorp posted:

If they're hiring PMs, they're not doing Agile (or at least, not by-the-book Agile), so you can throw that book out. Agile teams have 3 roles: the scrum master, the product owner, and software developers. Are they trying to fill the role of product owner or the role of scrum master, or are they not actually Agile?

Those are the roles in scrum. An agile team is not necessarily going to use scrum.

ultrafilter
Aug 23, 2007

It's okay if you have any questions.


Project managers are a vital part of doing software development at scale. You don't need them in a small company, but once you get past a certain point not having them is going to hurt a lot. Smart Agile shops realize that.

pigdog
Apr 23, 2004

by Smythe

Knockknees posted:

*I own and have read Cockburn's "Agile Software Development". I also know that they use some XP principles, and I've got that book too, but I haven't dived into it.
That is a fantastic book, and so is his "Crystal Clear" book. They are an outstanding reference for what agile really means; you're definitely not going wrong there.

The biggest doubt I have for your PM plan is that you don't have a software development background.

New Yorp New Yorp posted:

If they're hiring PMs, they're not doing Agile (or at least, not by-the-book Agile), so you can throw that book out. Agile teams have 3 roles: the scrum master, the product owner, and software developers. Are they trying to fill the role of product owner or the role of scrum master, or are they not actually Agile?

No offense but you're arguing from 101 level Scrum knowledge, which is one possible starting point of doing agile.

Of course there can be PM's in agile world too, because agile software development is part of the real world, and the real world often dictates that there are projects, budgets, plans, use cases, even deadlines. If the team uses Scrum, then the PM may take the role of Scrum PO where there's a lot of overlap.

fantastic in plastic
Jun 15, 2007

The Socialist Workers Party's newspaper proved to be a tough sell to downtown businessmen.

Knockknees posted:

So like, I can google "what is Elixir", but here's what I'm hoping to understand before I go in:

What are the things that are most helpful for you as a developer to have the PM understand?
What are the smart questions I should be asking?
As an industry outsider, what are the things I don't realize that I don't know about working in software?

I've been a developer at a small consulting agency. I think what New Yorp New Yorp said is pretty on point. To add to it, it's important to realize that programming needs a lot of mental concentration and focus. When a developer is in the zone, so to speak, even a brief "hey, can I grab you for just a minute..." distraction can be a blow to productivity. This essay expands on this idea with the concept of "maker schedule" and "manager schedule", and you might find it useful to read it.

I'd ask questions about how the company internally scopes projects, how the PMO estimates how much time a project will have budgeted for it, and when the company tells a client that they'll need a change order. My former employer was not good about this and got burned over and over by clients wanting "small changes" that cost the dev team dozens of hours of work or the client coming in every week with new requests that we've never heard of before. It sucks to be working on something and know that money's being left on the table or that the project timeline is now unrealistic and in a couple weeks the client is going to use the delays to argue that they shouldn't pay the full price.

In general, I think that's something important to recognize about software as an industry -- it's incredibly vulnerable to scope creep, and clients have a habit of blowing the scope by asking for an hour here, an hour there, and then before you know you're 16 weeks in to a 12-week project, the stakeholders are mad because you're a month behind schedule, the team doesn't trust you anymore because you keep dumping work on them, the account manager is wondering why the client isn't taking their calls any more... you get the idea. If you don't wind up being that kind of PM, I think you'll do better than a great many of them.

huhu
Feb 24, 2006
Peopleware is a great book about managing and working with software developers.

Gildiss
Aug 24, 2010

Grimey Drawer

huhu posted:

Peopleware is a great book about managing and working with software developers.

Started reading this tonight and it is pretty good.

Also recommend Mythical Man Month.

Jose Valasquez
Apr 8, 2005

Gildiss posted:

Started reading this tonight and it is pretty good.

Also recommend Mythical Man Month.

As a bonus, if you get 3 copies of Mythical Man Month you can read it 3 times as fast

Don't fall into the trap of thinking more resources automatically means quicker work

JawnV6
Jul 4, 2004

So hot ...

Knockknees posted:

I used to be a PM in another industry, but my job was awful and I left it. Now I want to do something new. I've successfully made it through a few rounds of interviews at a small software development consultancy, and now they've asked me to do a week-long audition.

As an industry outsider, what are the things I don't realize that I don't know about working in software?

What's the industry that you're transferring from? Honestly, if you were managing engineering projects with ME's or EE's, making the change over to software would be relatively easy. I don't find the value that some folks do in squabbling over "what ~*is*~ Agile??" but you do want to understand how their P's were M'ed before your arrival and not fight too hard against that process.

Adbot
ADBOT LOVES YOU

Shirec
Jul 29, 2009

How to cock it up, Fig. I

I am fresh from my interview, sitting in the airport, with a few hours to spare and unwind.

So, first off, I think it went amazingly! I got along well with all the interviewers, and in both sections of the technical portion (whiteboarding some problems and an ER diagram/rest apis), I was told I did really good! Had an excellent rapport, good handshake, and I like the company a lot.

Only section I am worried I flubbed was when I was explaining why I’d do the apprentice program when I’m currently a web dev and that when I told them I’m leaving my current job because they are offshoring development to where we’d be overseeing them (the interviewer said I’d potentially be working with offshore developers). To the first I said that I still only had a few months experience and the dedicated mentorship/learning thing was something I felt I would benefit from. To the second I said I had no problems working with any types of teams, the issue was that we’d be removed from programming and just given review responsibilities, which wasn’t what I wanted to do.

I should know on Friday or Tuesday what the answer is

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply