Job Questions

PerlSufi has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Job Questions by daxim (Curate) on Nov 18, 2013 at 16:11 UTC
http://modernperlbooks.com/mt/2012/07/perl-shop-maturity-checklist-technical-concerns.html http://modernperlbooks.com/mt/2012/07/perl-shop-maturity-checklist-social-concerns.html http://modernperlbooks.com/mt/2012/07/perl-shop-maturity-checklist-perl-specific-concerns.html http://www.joelonsoftware.com/articles/fog0000000043.html http://www.stefankendall.com/2013/11/10-questions-to-ask-your-potential.html https://github.com/ChiperSoft/InterviewThis http://www.theladders.com/career-newsletters/it-s-not-about-me--it-s-about-you----the-20-questions-you-need-to-ask-in-a-job-interview-June-2013 https://news.ycombinator.com/item?id=6702199 Buy petdance's book! → Land the Tech Job You Love	[reply]
Re^2: Job Questions by PerlSufi (Friar) on Nov 18, 2013 at 16:22 UTC
Awesome, daxim. Thanks a bunch. There are several questions on that first link that would be answered by 'yes' at my current $work, that should be answered 'no'. ;) ie: Do you have code that "no one knows what it does"?	[reply]
Re^3: Job Questions by stonecolddevin (Parson) on Nov 18, 2013 at 16:38 UTC
There's plenty of code that may as well be. I've had a few projects dumped in my lap with "Here, make this work, we need it done in a week." Then you just start adding `print` statements and slowly build your map around the code. It's tedious, and sometimes (actually almost always) painful, but you will gain a lot of respect for being autonomous and you will have a much better grasp of how the code works. Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past	[reply] [d/l]
Re: Job Questions by boftx (Deacon) on Nov 18, 2013 at 20:05 UTC
I have just recently added the following questions to my list: Do you have QA/Staging environments that accurately mirror the production environment? Do you use code review, and if so, must new code be approved by review before going to QA? Do you use dev and story branches or is it held that master must always be ready to push to production? If the latter, how do you avoid having un-reviewed code or code that has not gone thru a proper QA being pushed by accident? These questions might seem a bit forward given this stage in your career, but as time goes on you will understand why they could play a role in your deciding to take a given job. It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.	[reply]
Re^2: Job Questions by PerlSufi (Friar) on Nov 18, 2013 at 21:50 UTC
Thanks, boftx. Thanks to all of you, actually. Great insights!	[reply]
Re: Job Questions by BillKSmith (Monsignor) on Nov 18, 2013 at 16:48 UTC
Given the previous comments, it may be hard to ask, but one thing you really should know is the 'quality' of the requirements you will receive. Bill	[reply]
Re: Job Questions by taint (Chaplain) on Nov 18, 2013 at 16:06 UTC
So, big corporation, is it your hope, or intention to make me the wealthiest person on the planet? Good question -- no? Seriously, I don't mean to diminish, you, or the serious nature of your question. But honestly, isn't that really the bottom line? A couple of thoughts come to mind; First impressions are everything, and they do judge a book by it's cover. I'd hesitate to elaborate much further than that, except to say, that be cautious in your questions, lest you appear to be interrogating them. Always ask your questions in such a way, as to appear that your primary interests concern their best interest -- even if they aren't :) Best wishes, and good luck! --Chris #!/usr/bin/perl -Tw use Perl::Always or die; my $perl_version = (5.12.5); print $perl_version;	[reply]
Re^2: Job Questions by PerlSufi (Friar) on Nov 18, 2013 at 16:10 UTC
Haha, nice question taint.. and good recommendation on how to ask. I will definitely take that into consideration.	[reply]
Re^3: Job Questions by taint (Chaplain) on Nov 18, 2013 at 16:13 UTC
Really, I wish you all the best -- good luck! --Chris #!/usr/bin/perl -Tw use Perl::Always or die; my $perl_version = (5.12.5); print $perl_version;	[reply]
Re: Job Questions by stonecolddevin (Parson) on Nov 18, 2013 at 16:49 UTC
I've found that asking them what you can do to be successful (provided they haven't immediately just mentioned exactly that), and maybe cite some experience on what's helped you be more successful in the past. Get a grip on their expectations, and they tend to start spilling more and more candidly about the environment and things you'll be working on. Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past	[reply]
Re: Job Questions by sundialsvc4 (Abbot) on Nov 18, 2013 at 19:59 UTC
Only the code that I write is Perfect, Pristine, and Timeless. (There are only so many Perfect Coders allowed per planet, and I’m it.) All the code you’re likely to encounter will be old-crap that’s barely hanging-on on life support. `;-)` Seriously, most code is “already existing,” therefore “legacy.” The new code that you write, as soon as you write it, becomes part of that “legacy.” So, it is always an important skill to be able to assess the present-state of a piece of code, to fully understand the desired future-state, and then to be able to articulate and to estimate what it will take to move it forward ... and at what business-risk, and with what allowances for Sergeant SNAFU ... and how it will be testable and how it will be tested ... before you and/or your team starts to write it. Most of the time, you will find these practices are followed, because people really do need to write stuff that is more-or-less stable and that more-or-less stays that way. However, the code has been changed, many times and by many people over many years for many reasons. This is inherently de-stabilizing to software. The work practices are often most-important: how do they handle problem-reports and change requests? Do they use source-code control? What is their deployment procedure, and how do they recover from / roll back a deploy? How do they “mentor” new team members, such as you would be? These are things that you should ask during that same interview. Most programmer positions have little direct client contact. But you will still need to develop the ability to converse effectively with a non-technical person about a highly technical subject. You will need to be able to communicate effectively with members of your team, including those who know more and those who know less than you (about a particular subject area), and to work with them effectively as a team. Computer software is not the work of one person.
Re: Job Questions by Voronich (Hermit) on Nov 20, 2013 at 15:37 UTC
The fact that you're thinking this way and have these specific questions already means you're in pretty good shape out of the gate. Other people have covered the sensible additional questions and issues pretty well I think. Someone's perceptions of how well they follow best practices, et al, are almost always going to be better than they are. What I think you really want to hear is "not as well as we'd like, but we're pulling in that direction." More likely you'll hear "Yes, We're leet!" in an attempt to impress. Which, meh, they're human, it's what to expect. You could cut through a lot of bullshit if you could get them to give you a specific real life example of a couple assignments. Reaction to that kind of a question will tell you volumes.	[reply]
Re^2: Job Questions by PerlSufi (Friar) on Nov 20, 2013 at 15:42 UTC
Great response, Voronich. Good call on getting them to give me some real life examples, too. I'll see if I can do that	[reply]
Re^3: Job Questions by Voronich (Hermit) on Nov 20, 2013 at 15:51 UTC
People can be hesitant to do that, which can be telling of a couple things. They might not want to say because it reveals too much about their business in some way. Or perhaps because they're bashful about their code. You'll be able to tell by the interviewers behavior I'm sure. I was asked a really great, detailed, squirrely debugging/diagnosis question a few jobs ago. After a really entertaining 10-15 minutes or so of asking follow up questions to try and solve the problem, I diagnosed the problem and provided the sequence of steps required to solve the problem. Then it suddenly struck me what was going on. It was easily as much fun as I've had on an interview in a very long time.	[reply]
Re: Job Questions by Bloodnok (Vicar) on Nov 19, 2013 at 10:56 UTC
I'm not sure if it isn't a tad off-topic but I've always found i.e. without exception, that the best jobs I've taken - whether perm or contract - have been those where the interviewer(s) spend as much time 'selling' the company as giving me the 3rd degree. The two instances where the interview was all about the 3rd degree were jobs I wished I'd never accepted and left both after less than 6 months - since when the above maxim has worked fine ... for me anyway:-) A user level that continues to overstate my experience :-))	[reply]
Re^2: Job Questions by PerlSufi (Friar) on Nov 19, 2013 at 14:39 UTC
What do you mean by the 3rd degree?	[reply]
Re^3: Job Questions by ww (Archbishop) on Nov 19, 2013 at 14:45 UTC
Gee, that would be really hard to Google. - - (for lack of effort). Update: Search Term: "the third degree" Google's response: https://www.google.com/search?q=%22the+third+degree.... Content brief of first hit: Third degree (interrogation) - Wikipedia, the free encyclopedia en.wikipedia.org/wiki/Third_degree_(interrogation)‎ The third degree is a euphemism for the "inflicting of pain, physical or mental, to extract confessions or statements". In 1931, the Wickersham Commission found ... Afterthought: mid-part of first para probably should have been "...would have been really..."	[reply]


Think about Loose Coupling
	PerlMonks