Iyfjky

Question

I am a fresh graduate and currently working as a programmer under probation. The probation period is going to end this week. This is my first job in the software industry.

The company I'm working for does not utilise any best practices for programming, such as software development methodology, unit testing which I'd like to learn more about. There is also communication issues between the programmer (me) and the project manager, as the project manager talks to team leader only, and team leader overestimates my ability most of the time. I've talked to team leader but he does not seem to listen to me and that makes me think of leaving this company.

My main question is: How do I find out my next potential employer does utilise programming best practices during an interview? The obvious answer I could think of is ask them directly, but that might be blunt.

For your information, this is a startup company. The project we are developing is a medium scale web application. The team leader helps in designing user interfaces while I'm in charge of all of the server code and integrating the design from the team leader. There's no any design except an ambiguous function specification document, so I have to do all the things, including database design, single-handedly.

Thank everyone who has left a comment below, your comments are helpful.

Please read other answers because they are very useful too, especially this one (It is not marked as the correct answer because it does not answer my question).

possible duplicate of Is it reasonable to quiz the interviewer during technical interviews? "I want to make sure that I am moving to a company who values quality software and employs experienced engineers..." — Mar 18 '14 at 19:13
Hey pikachu, and welcome to The Workplace! Could you clarify your question with an edit please? It sounds like you have several issues: (1) communication with your boss, (2) quantity/level of work, (3) deadlines, (4) process. It sounds like you've already decided to leave for another job and want to know how to ask about these things in the process of finding a different company. Could you clarify what exactly you want to know ('real world skills' is a bit vague)? It may help get better answers. Thanks in advance! — Mar 19 '14 at 0:24
This is several good questions rolled into one: a) What are reasonable real-world expectations about the development process b) How to identify a good company c) How to make the interview work d) How to effectively advocate for changes in your current company e) Career management: who to talk to about, what, when, and how to gradually drive change and build credibility. For this last one, keep your suggestions short, focused on solutions to things they perceive as burning issues. Introducing a bug-tracker is a great start. — Mar 21 '14 at 12:26
No testing? Poor communication? Overworked programmers? Sounds as real world as it gets! — Feb 7 '17 at 7:44
After 3 years working in another bigger company, I came to realize how naive I was. — Mar 6 '17 at 22:52

NotVonKaiser 6,5151533 · Accepted Answer · 2014-03-18 19:20:27Z

So... not to be too harsh about this, but these situations you're describing? They kind of are "real world techniques". In theory, sure, it would be fantastic if you always entered into a place with a robust unit testing program, a well-documented software lifecycle, or even decent source control, but the reality is that often you're going to find yourself kind of thrown into a project to "make something work". From there it's up to you to implement all of that other stuff. Unfortunately, the reality of the world today is that being an in-house dev who translates non-techie requirements into actual features is a "real world technique".

That being said, it can be tricky to learn how to do all of this kind of thing without somebody showing you how in the beginning. If you're looking for a place which will implement all of the structure, I'd perhaps ask the following questions:

How large of a group shall I be working with (if the answer comes back "oh, you'll be by yourself", then assume there is no programmer-friendly protocol put into place)?

What is your software lifecycle process like?

What unit testing protocol do you use?

It's perfectly okay to ask questions like this during an interview; indeed, stuff like this is reason #1 why there is usually time for the interviewee to ask questions. The interview process is as much a chance for you to figure out if the company is the right fit for you as the other way around.

I ask these questions every interview. I want to know that I'll enjoy doing things they way the team does it before I sign on. — Mar 19 '14 at 15:04
@2rs2ts: Ã¢Â€ÂœI want to know that I'll enjoy doing things they way the team does it before I sign on.Ã¢Â€Â ThatÃ¢Â€Â™s tricky to actually achieve, unless you can communicate a pretty detailed description of what practices you enjoy, and get a detailed description of how a given team works. If youÃ¢Â€Â™re early in your career, itÃ¢Â€Â™s probably more worthwhile to get experience (even unenjoyable experience). ThatÃ¢Â€Â™ll make it easier to identify places you want to work in future. Once youÃ¢Â€Â™ve got some experience, itÃ¢Â€Â™s less risky to quit during a probation period if you donÃ¢Â€Â™t like how the team functions. — Mar 20 '14 at 15:02
Of course. You can only really get a high-level description of how things run. Normally, I ask about the revision control system the team uses, whether a formal process exists and if so what it is, team size, frequency and duration of meetings, management structure, code review conventions, whether IM is used or team members must walk to each others' workspaces to communicate quickly, et cetera. Things like that. I can piece together team dynamics from the choices of technologies especially. — Mar 20 '14 at 15:38

jmac 19.4k763137 · Answer 2 · 2014-03-19 02:58:39Z

As stated by everyone else, unfortunately, what you have described is the "real world".

I have heard rumors of the mythical organizations where the highest level of CMMI is acheived, BDD/TDD is budgeted for and employed, requirements are well documented and are both accurate and unchanging, S.O.L.I.D. architectures principles are adhered to, there are no over estimations of the ability to produce a feature in a given time frame, there is active open and honest communication between project managers, team leaders, and developers, and you actually like the people you work with, but I think these organizations all reside in Shangri-La somewhere on the Western end of the Kunlun mountains...you often can find an organization with one or more of these characteristics, but rarely with them all (I tend to opt for the ones with people I like to work with).

It seems that you have pretty much decided to leave, so here is my answer to your question about how to find out whether future potential employers use these techniques on a day to day basis:

It is perfectly fine to ask about such things in an interview, but don't expect to always get an honest up front answer.

I'll explain.

Companies tend to want employ developers that are concerned about such things as mentioned above.

Companies are made up of individuals.

Individuals are known to lie or stretch the truth (speak of hopes and dreams as realities) to either get what they want or to not appear to be incompetent.

Therefore, companies will often lie to you (or be misleading/not be completely forthcoming), about whether employing all of the techniques listed above just to get a great prospect like yourself.

Now, they may have plans to do all of these things or they may have some individual developer who does them just to stay sane, so technically they were telling the truth, but the only way you'll get the real scoop is to talk with someone in the trenches who has nothing to gain by lying to you.

This is one time it would actually be preferable to speak with someone who is negatively biased and/or disgruntled, because it'll take them about 5 minutes to fill you in on the real scoop.

At any rate, you can take heart. This too shall pass. Look at every experience as just that...more experience. Seek methods to increase communication between the team. Start taking charge of the design of whatever is under your control and code it like a BOSS. Be sure to leave everything you touch in a better state than what you found it so that it is clear that pikachu0 has been here. Then document it all on your resume.

Is your Team Lead over optimistic? Factor that into the estimates you give him. At the end of the day, if your actual time matches what's recorded for your estimated time, you come out looking much better...so estimate to offset his under-estimation.

You want to employ TDD? Do it. Make it part of the development process for yourself. If inquiries are made into why you're doing something, respond that "this is the way I write code...this is the right way to write code...I don't know of any other way to write code".(<-- period!)

The ability to successfully navigate challenging situations are what potential employers want from an applicant. You're going to have customers, end users, co-workers, and clients that are worse...much much worse, so you need to be able to develop those interpersonal skills that will allow you to navigate these treacherous waters safely.

You also must just take control of your technical career. If you can't do it on the job, start a side project to pickup the skills you want. You can come in early to do it or stay late to get it done. Yea, no one likes working for free, but it'll pay dividends exponentially when you have mastered an in demand skill set.

And don't stress. You're a recent grad, so you may be nervous about retaining employment, but if you're committed to producing quality software, then you're already in high demand and you'll be in even higher demand as soon as you get a few years of experience to go along with your cutting edge skills.

+1 for "You want to employ TDD? Do it." It's easy to complain that things aren't the way they should be. The question is, what are you going to do to fix it? Especially in a startup, where taking the initiative is crucial. — Mar 19 '14 at 1:43
I'd give you 2 upvotes for Shangri-La and "(<-- period!)" if I could. — Mar 19 '14 at 1:48
Hey De Shan, and welcome to The Workplace! Great first answer. I made a few cosmetic changes, please feel free to edit if you think your post can be improved or if I missed something/screwed something up. Welcome again, hope to see more answers from you in the future! — Mar 19 '14 at 2:59
I stopped reading when I saw lots of acronyms that I don't know what they are. — Mar 19 '14 at 15:33
You need to be careful in a start-up - it's the worst place for a first job. I've actually been reprimanded for taking the initiative - and I was hired for a leadership role. My leadership skills were embarassing one of the founders of the company, because I basically jumped in where he was failing, so I got dinged for making him look bad, not for getting the job done. My response was something to the effect of "well, we're here to get shit done, right?" — Mar 20 '14 at 22:34

Communityâ™¦ 1 · Answer 3 · 2017-04-12 07:31:57Z

Unfortunately, the things you see are extremely common in the "real world." I have worked in software at three different companies. None of them follow exactly any "best practice" although some try harder than others. To get an idea of the scope of "standards" that are out there, check out this programmers link. Seriously, there are some bad ideas out there.

The only way to get a feel for what they do is to probe during the interview. Ask them what they use for SCM, issue tracking, and project management software. Ask them what kind of dev/test environment they have, if they use unit testing.

So, yes, ask them directly, but respectfully. As a developer these are very pertinent questions and any employer that disapproves of your asking them is not someone you will want to work for.

score 10 · Answer 4 · 2014-03-19 11:18:00Z

You should take a look at The Joel Test, blogged by Joel Spolsky. As someone who recruits developers from time to time, I would be happy to be asked any or all of these questions during an interview. Indeed, I would look favourably on someone who knew these questions existed and was interested in the answers.

That might not be true of all interviewers. But maybe you don't want to work for those interviewers?

In the linked article, Joel lists 12 things that he believes all good software development shops should do, but which many do not. Number one on his list, for example, is "Do you use source control?"

Joel, of course, claims to have founded Fog Creek so that programmers could find a place to work which would answer "yes" to all 12 questions Ã¢Â€Â“ as very few (no?) places could have done at the time he originally wrote the article back in 2000.

Even now, you are unlikely to get 12 yes answers in most places, but each "yes" you do get represents a step along a route towards Joel's view of professionalism.

Asking these questions, around the time the interviewer asks "do you have any questions for us" has a number of benefits:

You learn how the company operates, and whether they think about this stuff

By invoking an external authority, you reduce the risk of provoking a bad reaction

You demonstrate that you read programming blogs, which immediately puts you in the top 10% (or so) of developers, at least in the mind of people who care about these things

Based on your question, you probably want to work for someone who cares about these things

Ultimately, you may not agree that all 12 items are equally important, but as a starting point, they are great.

The full list (which is expanded on greatly in the original article) is:

The Joel Test

Do you use source control?

Can you make a build in one step?

Do you make daily builds?

Do you have a bug database?

Do you fix bugs before writing new code?

Do you have an up-to-date schedule?

Do you have a spec?

Do programmers have quiet working conditions?

Do you use the best tools money can buy?

Do you have testers?

Do new candidates write code during their interview?

Do you do hallway usability testing?

would you mind explaining more on what it does and why do you recommend it as answering the question asked? "Link-only answers" are not quite welcome at Stack Exchange — Mar 19 '14 at 10:16

Thalaivar 1,6491114 · Answer 5 · 2014-03-18 19:11:22Z

The company I'm working for does not utilise real world techniques,
such as software development methodology, unit testing which I'd like
to learn more about.

If your area of interest lies some where, you need to travel along those lines. Some companies don't add weight to these practices and you would get some other things to learn. As long as you are learning something new everyday, its all good considering you are a fresh graduate.

Most of the startup's are informal. What you are expecting is a traditional company with their own set of process. The culture is different in startup's and it varies. I can understand your situation where you have handle too much work, but believe me you will learn a lot and you will learn how to do things individually.

How do I find out my next potential employer does utilise real work
techniques during an interview?

You will have a round with either PM or VP of product after the technical discussion. Ask questions ranging from technology stack used for development, unit-testing framework used, front-end framework/libraries used. You could also ask about the work culture, dress-code, timings.Ask about their product, their clients.

Also ask on their revision system, do they have scrum if so are they using any tools.

With these set of questions you get an idea overall on what and how they are structured in technical/development wise.

score 2 · Answer 6 · 2014-03-20 11:33:54Z

That's the catch isnt it

Fresh out college, you start working somewhere in an IT environment and everything you learned about standards and practices in computers and programming goes out the window. You look around you say to yourself, "huh, thats not the way we should be doing things and I'm doing work for 5 people"

That's exactly what happened to me 25 years ago and probably to millions of people fresh out of college working in IT.

Unfortunately, speaking from experience you find this to very common in the IT industry, some places luck the cash to impose good standards and hire staff they need others have too much cash and they experiment with different standards and employ thousands of people and others don't have the time or know how to impose good standards.

Fact of the matter is that the IT industry itself is moving so fast keeping standards is very hard. Take ITIL as an example. How many places out there implement it. Probably a fifth or less. And its meant to be the bible for any IT workplace. At least parts of it.

Ok so your question is How do I find out my next potential employer does utilize programming best practices during an interview?

That's a tough one.

You will have to do some research, find out about the company and get as much info as possible, check their website and get a feel about how they do things. Usually IT websites revolve around promoting how good they are and their products but thats not what your looking for.

But keep Checking they may have a page about best practices and ethics, usually companies do. Maybe some youtube videos.

You shouldn't ask that question in an interview, its sounds a bit broad, plus what if the person replies to you with "I don't know, I'm not a Programmer, I'm an IT manager". I had an IT manager once he never said "Send me an Email", he said "Ping me an Email". I used to think, Yea ok ill Ping your IP address, how about that. So my point is Whoever is interviewing you may not know much about JAVA or PERL or C or JQUERY or HTML5 or Programming. But they are the best at what they do Manage an IT environment. Being good at Management and making the best decisions and utilize expenditure and Budgets and so forth, and also spot good people to work for them.

So its better if you say "And i learned/studied to Follow best Practices in Programming" and see what the reply is. If they say "No one bothers with that here, we do things on the fly" or they say "That's good that exactly what we aim and adhere to here because we believe in that" then you know.

Be careful though, they may ask you "So, What are the best practices in Programming?" and then you draw a blank. Everything you knew and felt so strongly about cant be accessed now because you didn't sleep that great the night before. So be prepared if they ask you.

Usually getting a job and being successful at interviews comes down to how much they liked you as a person and your personality and how you think and not so much about programming best practices.

Chances are any questions you have in mind will be answered without asking the questions.

Good Luck and i hope you get you dream job and be happy.

bobo2000 6,006113156 · Answer 7 · 2017-02-06 13:48:53Z

As others have said, in an ideal world you would be working on a project that employs best practices. The reality from my experience working in many tech start-ups is that there is intense pressure to get to market from having a limited budget. Hence, best practices are not always followed e.g. TDD/BDD etc to speed up the development process. Is this a wrong approach? In my opinion, no, and it is subjective. I have worked with test driven developers who have produced buggy code despite writing tests to the point at my current company we ditched the tests in order to get to market quicker with the view to add tests once the product matures. Maybe your company is taking a similar approach?

score -1 · Answer 8 · 2014-03-20 16:25:33Z

the project manager talks to team leader only, and team leader overestimates my ability most of the time.

...

There's no any design except an ambiguous function specification document, so I have to do all the things, including database design, single-handedly.

It sounds like youÃ¢Â€Â™d ideally like some mentoring from a senior programmer, given that youÃ¢Â€Â™re fresh out of college. If and when you do leave this job, in future interviews, mentoring is the thing to ask about.

My last two jobs have recognised that taking on junior developers and mentoring them a bit is a good way to attract young developers, get the most out of them, and help the seniors develop too (because when we teach, we learn).

Yes, but if the current company don't care about the people or the process, they're not going to do this, and can't be persuaded to. These are good points for OP's search for his next company. — Mar 21 '14 at 12:21
@smci: oh sure, it doesnÃ¢Â€Â™t sound like thereÃ¢Â€Â™s much chance of mentoring at the OPÃ¢Â€Â™s current workplace. — Mar 21 '14 at 14:14

NotVonKaiser 6,5151533 · Accepted Answer · 2014-03-18 19:20:27Z

So... not to be too harsh about this, but these situations you're describing? They kind of are "real world techniques". In theory, sure, it would be fantastic if you always entered into a place with a robust unit testing program, a well-documented software lifecycle, or even decent source control, but the reality is that often you're going to find yourself kind of thrown into a project to "make something work". From there it's up to you to implement all of that other stuff. Unfortunately, the reality of the world today is that being an in-house dev who translates non-techie requirements into actual features is a "real world technique".

That being said, it can be tricky to learn how to do all of this kind of thing without somebody showing you how in the beginning. If you're looking for a place which will implement all of the structure, I'd perhaps ask the following questions:

How large of a group shall I be working with (if the answer comes back "oh, you'll be by yourself", then assume there is no programmer-friendly protocol put into place)?

What is your software lifecycle process like?

What unit testing protocol do you use?

It's perfectly okay to ask questions like this during an interview; indeed, stuff like this is reason #1 why there is usually time for the interviewee to ask questions. The interview process is as much a chance for you to figure out if the company is the right fit for you as the other way around.

I ask these questions every interview. I want to know that I'll enjoy doing things they way the team does it before I sign on. — Mar 19 '14 at 15:04
@2rs2ts: Ã¢Â€ÂœI want to know that I'll enjoy doing things they way the team does it before I sign on.Ã¢Â€Â ThatÃ¢Â€Â™s tricky to actually achieve, unless you can communicate a pretty detailed description of what practices you enjoy, and get a detailed description of how a given team works. If youÃ¢Â€Â™re early in your career, itÃ¢Â€Â™s probably more worthwhile to get experience (even unenjoyable experience). ThatÃ¢Â€Â™ll make it easier to identify places you want to work in future. Once youÃ¢Â€Â™ve got some experience, itÃ¢Â€Â™s less risky to quit during a probation period if you donÃ¢Â€Â™t like how the team functions. — Mar 20 '14 at 15:02
Of course. You can only really get a high-level description of how things run. Normally, I ask about the revision control system the team uses, whether a formal process exists and if so what it is, team size, frequency and duration of meetings, management structure, code review conventions, whether IM is used or team members must walk to each others' workspaces to communicate quickly, et cetera. Things like that. I can piece together team dynamics from the choices of technologies especially. — Mar 20 '14 at 15:38

jmac 19.4k763137 · Answer 10 · 2014-03-19 02:58:39Z

As stated by everyone else, unfortunately, what you have described is the "real world".

I have heard rumors of the mythical organizations where the highest level of CMMI is acheived, BDD/TDD is budgeted for and employed, requirements are well documented and are both accurate and unchanging, S.O.L.I.D. architectures principles are adhered to, there are no over estimations of the ability to produce a feature in a given time frame, there is active open and honest communication between project managers, team leaders, and developers, and you actually like the people you work with, but I think these organizations all reside in Shangri-La somewhere on the Western end of the Kunlun mountains...you often can find an organization with one or more of these characteristics, but rarely with them all (I tend to opt for the ones with people I like to work with).

It seems that you have pretty much decided to leave, so here is my answer to your question about how to find out whether future potential employers use these techniques on a day to day basis:

It is perfectly fine to ask about such things in an interview, but don't expect to always get an honest up front answer.

I'll explain.

Companies tend to want employ developers that are concerned about such things as mentioned above.

Companies are made up of individuals.

Individuals are known to lie or stretch the truth (speak of hopes and dreams as realities) to either get what they want or to not appear to be incompetent.

Therefore, companies will often lie to you (or be misleading/not be completely forthcoming), about whether employing all of the techniques listed above just to get a great prospect like yourself.