Interview
in [Java Help]
|
From: Lew on 3 Oct 2009 11:35 Patricia Shanahan wrote: > In order for a manager-developer coalition to work well, each has to > believe the the other has valuable skills and knowledge, and that both > will do better work, and get more pay increases etc., if they listen > respectfully to each other and use each other's knowledge. A good busboy makes the waiter more money, which they share with the busboy. Busboys are part of the sales team. - from /Everything I Need to Know as a Software Developer I Learned as a Busboy/, by Lew Bloch. -- Lew
From: Kevin McMurtrie on 3 Oct 2009 12:59 In article <4ac40260$0$21109$ec3e2dad(a)unlimited.usenetmonster.com>, "Ken T." <nowhere(a)home.com> wrote: > I had an interview today. It didn't go as well as I would have liked. > It didn't go badly but I wasn't familiar with everything my potential > employer did. > > When did it become necessary for a developer to not only know the > language used inside out, but also the APIs used, the third party tools > used, and basically to have done the same job for the last five years. > > I thought that the whole point of a good computer science education was > that you could apply what you learned to any language or API. > > BTW, this was for a Java position with a focus on Swing. I'm an expert > Java developer and a damn good swing developer. There are just parts of > the API swing API that I have yet to have needed and those I'm unfamiliar > with (many having to do with look and feel). There's no way of knowing from this post what happened. Here's a generic list of things that typically go wrong. - Some job postings are fakes used for various accounting and HR balances with the government. You don't want to work at a company that needs to do this. - You answered questions incorrectly. This is at least 10 times worse than asking for help to solve a problem. Coworkers would rather offer help on new code than clean up old code. - The job description may have been written poorly or needs might have changed. Your skills might not have been a match at all. - The employer felt that you didn't research position, the company, and the company's market sufficiently. It's a symptom laziness or salary shopping. - Too much work diversity in a big, old corporation. Excessive change is extremely expensive on large scales. - Too little work diversity in a small, young company. With little funds and little existing infrastructure, they need people who can quickly adapt to technologies with the highest ROI. - Lack of initiative or progress in career. Applicants who are entry level or moderately good for too long might be seen as weaker long-term investments than inexperienced applicants with lesser skills. - Misc: Your cellphone rang, you didn't bring pen and paper or a laptop, you interrupted the interviewer too often, you did not show pride in your work, your personality wasn't a good fit, the receptionist said you were rude, etc. -- I will not see your reply if you use Google.
From: Patricia Shanahan on 3 Oct 2009 16:06 Dave Searles wrote: > Patricia Shanahan wrote: .... >> In order for a manager-developer coalition to work well, each has to >> believe the the other has valuable skills and knowledge, and that both >> will do better work, and get more pay increases etc., if they listen >> respectfully to each other and use each other's knowledge. > > This is certainly true. It's a shame that many managers apparently don't > realize this, and hire technical people and then expect them to just > grind away in a dark room somewhere while being kept in the dark and fed > bullshit, their own input on technical matters either ignored or even > actively discouraged/avoided. I've seen it go wrong the other way round just as often. The developer does not listen when the manager says, before the meeting "I believe you when you say option A is technically best, but it is not on the table because of business issues X, Y, and Z." The developer goes on trying to push A, wasting everyone's time and the developer's credibility. The other participants in the meeting have got used to ignoring the developer by the time they get into the B vs. C discussion. An effective manager-developer coalition depends on each participant respecting and learning from the other's judgment in their areas of expertise, not just the manager listening to the developer. Patricia
From: Dave Searles on 3 Oct 2009 17:19 Arved Sandstrom wrote: > Dave Searles wrote: >> Arved Sandstrom wrote: >>> In all of these cases there were nuances as well. In the first case >>> the vendor officially supported over three-quarters of our installed >>> software. If we had replaced the small piece that was flawed with an >>> open-source implementation, the argument was that the vendor would >>> have refused to deal with any problems related to the entire stack. >>> Not inconceivable. That's political, but it's also a decent argument. >> >> The correct way to deal with that is to tell the vendor all about the >> flaws in the small piece, and if the vendor wouldn't do anything about >> that, go with the open source replacement for that component. And of >> course what the vendor doesn't know won't hurt it; no need to specify >> that that component was replaced. Just tell the vendor if some other >> component has problems what the inputs to it were and what the >> incorrect output was. If the output was clearly not what should have >> resulted from the inputs, the vendor can't very well argue, regardless >> of where those inputs actually came from. > > Depends on the vendor involved. This particular vendor happens to be in > the Top 5 of global IT companies by annual revenue, so if they intimate > that support for problems with your installation of their software stack > is contingent on not screwing around with that installation, including > swapping out pieces for third-party software, it's probably a good idea > to listen to 'em. In other words, they use a near-monopoly power to bully their customers around and make life difficult for them if they have a component acting wonky? This vendor's name wouldn't happen to be nine letters long and starting with an M, would it? >> Unless the vendor is irrational, of course, in which case the vendor >> is going to turn into an anchor tied to your foot and drag you down >> sooner or later. Get one that isn't crazy, ASAP, or go open source for >> the whole stack, and then you can fix things yourself using in-house >> expertise or using a company like Red Hat that sells support services >> for open source systems. > > As to the latter, a vendor like Red Hat sells support for _their_ > systems, OSS or otherwise. The point being, you can use OSS and still be using something the vendor supports in this case. > IOW, you don't generally select a piece of > third-party software because it's open-source, you select it because > it's the best software for the job. But what is "the job"? It might include making it easier for you to self-support if you have to. Or it might not. It depends on what is meant by "the job" in a particular case. >>> In the other two cases I mention there were actually larger project >>> issues involved - possible retraining of internal staff, or hiring >>> more external people, extending deadlines etc. >> >> That seems to me to depend on what was being done. For example, with >> retraining of internal staff, the problem would be that some user >> interface was being changed. If the product being contemplated was >> well designed, the UI and the engine would be decoupled enough that >> the UI could be replaced or reconfigured so retraining wouldn't be >> needed (except maybe all those workarounds for annoying known bugs >> could be happily forgotten about). If the product being contemplated >> was not well designed, then it fails on the merits anyway. > > In this case there would have been technology changes involved. The > internal staff would have been programmers and operations support. You > don't lightly propose changing technologies, even if the target > technology is a much better solution for the problem, without taking > those kinds of resource issues into account. Then you may be sunk, stuck in a quagmire from having backed the wrong horse at some point. Maybe you backed Eiffel back in the day and then Java's what took off, for instance. >>> This is all political stuff. And unless you're a software developer >>> on the bottom rung (and maybe not even then) you'll have a happier >>> career if you learn how to take it into account. You certainly don't >>> have to, but you'll end up frustrated and bitter if you don't. >> >> If you don't, AND work for the wrong sorts of people, perhaps. > > You'll never work for a company that has no politics. I would think that a company that minimizes politics, or at least minimizes the collision of politics with the technical hires, will be able to outcompete any companies that don't. So if what you say is true, it is also probably an unstable state of affairs that will not last indefinitely. Like an excited quantum state or a stock market bubble, the bottom will drop out from under such a system eventually.
From: Dave Searles on 3 Oct 2009 17:22
Patricia Shanahan wrote: > Dave Searles wrote: >> Patricia Shanahan wrote: > ... >>> In order for a manager-developer coalition to work well, each has to >>> believe the the other has valuable skills and knowledge, and that both >>> will do better work, and get more pay increases etc., if they listen >>> respectfully to each other and use each other's knowledge. >> >> This is certainly true. It's a shame that many managers apparently >> don't realize this, and hire technical people and then expect them to >> just grind away in a dark room somewhere while being kept in the dark >> and fed bullshit, their own input on technical matters either ignored >> or even actively discouraged/avoided. > > I've seen it go wrong the other way round just as often. The developer > does not listen when the manager says, before the meeting "I believe you > when you say option A is technically best, but it is not on the table > because of business issues X, Y, and Z." The developer goes on trying to > push A, wasting everyone's time and the developer's credibility. Is it a waste of time? Perhaps the developer is convinced that issues X, Y, and Z are outweighed by how much better A is than B. What is he supposed to do then, NOT give his honest opinion? THAT would undermine his credibility. Lying would undermine his credibility. > An effective manager-developer coalition depends on each participant > respecting and learning from the other's judgment in their areas of > expertise, not just the manager listening to the developer. When it comes to a technical decision, though, the area of expertise in question is the developer's. Managers have no business deciding whether to use mergesort or a hybrid insertion sort for the edge-sorting in the polygon engine. |