|
tef posted:goog tend to hammer people about algorithms in the hiring process. I was going to say. Speaking as somebody fitting the latter category, it's surprising how little genuinely advanced and complex code we write 
|
#
?
Aug 23, 2011 09:44
|
|
|
|
| # ? Apr 29, 2024 13:47 |
|
|
business logic is not really amenable to algorithmic analysis, it shouldn't be that surprising
|
|
#
?
Aug 23, 2011 11:20
|
|
|
tef posted:business logic is not really amenable to algorithmic analysis, it shouldn't be that surprising This is the reason I solve Project Euler problems on my free time.
|
|
#
?
Aug 23, 2011 15:26
|
|
|
tef posted:business logic is not really amenable to algorithmic analysis, it shouldn't be that surprising
|
|
#
?
Aug 23, 2011 15:35
|
|
|
I'd guess that was the distinction I was looking for - i.e. a software engineer at Google and a software engineer at IBM are going to be doing very different things. (As far as I know Google always advertises its positions as 'Software Engineer'?). For example, a friend is an extremely good software engineer, knows Java inside out, and is on nearly £100k final salary for doing what he does. Ask him to knock up a Quicksort algorithm, or what its time complexity is, and I think it's safe to say he wouldn't have a clue. I guess the answer is don't apply for jobs at Google; but then surely they must have a need for application/solution/system builders and not just algorithm gods.
|
|
#
?
Aug 23, 2011 16:22
|
|
|
iam posted:I'd guess that was the distinction I was looking for - i.e. a software engineer at Google and a software engineer at IBM are going to be doing very different things. (As far as I know Google always advertises its positions as 'Software Engineer'?). No one fresh out of school can cut the mustard as a systems architect at Google, that's predicated on years if not decades of real world experience. Algorithms and clever thinking are much easier to test on.
|
|
#
?
Aug 23, 2011 16:28
|
|
|
Google will also test your algorithms but that doesn't mean you'll actually be using algorithms there at your job. I know a number of people that work there that says despite having to solve algorithm problems at the interview, they haven't ever used their algorithm skills on the job. Of course I'm sure there's some people here that work at Google that could chime in that might have different experiences, I'm just relaying what I've heard.
|
|
#
?
Aug 23, 2011 16:39
|
|
|
I don't think the point is "Can you come up with and analyze algorithms cause that's what you'll be doing all day?" so much as "Are you a smart fucker who's comfortable enough with discrete logic and making machines do things to be able to adapt to whatever project we throw you into?"
|
|
#
?
Aug 23, 2011 16:51
|
|
|
Orzo posted:Agreed, and I'd say this is basically the difference between software engineering and computer science respectively. I wouldn't. I'd say that computer science, while poorly named, is a term that means something while "software engineering" doesn't have any standard definition, and the most common usage thereof has little or nothing to do with engineering*. Few people who call themselves software engineers have any engineering background, schooling or experience, and for the most part any they do have is ad-hoc. The discipline itself lacks a solid theoretical foundation, which more or less gives the game away right there - consider some kissing cousin fields like electrical engineering and systems engineering. EE tools and techniques like node voltage analysis and mesh current analysis are outgrowths of scientific theories in which we are confident, namely Kirchoff's laws. In systems engineering, techniques to design and analyze control systems like root locus anaylsis are based on the control theory developed by Bode and Nyquist. In software engineering, our techniques are based mostly on shamanism and fads that resemble nothing so much as management; many of the problems which we consider software engineering problems are really organizational problems. To the extent what we do anything that resembles engineering practice, we still manage to turn it into superstition - consider how unit testing became Test Driven Development. The funny thing is, there has been a lot of engineering work done with relation to the design and analysis of software and hardware/software systems. Almost all of it has been done under the banner of CS or EE or one of EE's bastard children. I would go so far as to say that for software related systems, the likelihood of engineering being involved is inversely proportional to the frequency the term "software engineering" being used. * google "software engineering isn't engineering" and you'll get a million relevant things along these lines Blotto Skorzany fucked around with this message at 19:22 on Aug 23, 2011 |
|
#
?
Aug 23, 2011 19:19
|
|
|
Otto Skorzeny posted:To the extent what we do anything that resembles engineering practice, we still manage to turn it into superstition - consider how unit testing became Test Driven Development. This bit is actually demonstrative of two different things, so I'll give it its own post to elaborate. On the engineering level, unit testing is more or less a port of the common engineering practice of breaking a system into its component parts, recursing on the components until we've got more or less atomic components, testing those to make sure they work, and then "bubbling up the stack" and combining subcomponents into components and testing them, until we're back at the top level and can test the system as a whole to ensure it works. In our software development culture with very complex systems that are never really finished we often use testing as a replacement for a formal spec such that we can diddle with or replace implementations or components and have assurance we haven't broken anything, but the concept remains applicable. Parts of our culture, however, having tasted the benefits of introducing this little bit of rigor and decided that it's a magic wand, a silver bullet which will solve all of our woes if only we add some hocus pocus. So we sort of ironically add process in search of rigor with no rigorous reason to add anything, to say the least of the particular things we are adding and end up removing real rigor if anything by doing so. On the computer science level, it probably jumps out to you that the recurse-down-then-build-back-up style to testing resembles the classic divide-and-conquer approach of many algorithms! The analogy isn't perfect, but you see it right away or at least go "ah-ha!" when it's pointed out if you have even a lick of algorithmic knowledge. This sort of recognition will allow you, when you encounter a problem, to think of what kind of algorithmic approach you might want to use if your naive approach isn't performant enough. While you may remove a level of rigor from your algorithms class and eg. code up a solution and see if it's faster enough rather than consulting the master theorem of recurrence relations to see if its asymptotic time constraints should be better, you're at least subconsciously doing this sort of CS stuff and devising algorithms even if you don't know you are whenever you do anything technically novel. For this reason I am skeptical that the Google folks have never used data structures and algos after their interviews - it's unavoidable unless you're pushing any technical boundaries. (This isn't to say a project that merely combines and applies known components isn't novel at all - it may well be breaking new ground in other areas. Many startups fit in this category).
|
|
#
?
Aug 23, 2011 20:42
|
|
|
It probably varies too much by the company for this question to be worth much, but I'll ask anyway. For a first job, assuming two roughly equal positions, would I be better off looking at a small company or a large one?
|
|
#
?
Aug 23, 2011 21:00
|
|
|
Dire Penguin posted:It probably varies too much by the company for this question to be worth much, but I'll ask anyway. For a first job, assuming two roughly equal positions, would I be better off looking at a small company or a large one? Depends on what you're looking for. A larger company will typically be more stable and might be able to provide you more flexibility in where you go after that initial position. A smaller company might be a little riskier but it might allow you to stand out more amongst your peers and get noticed. Just "size" (whether it be headcount or revenue) doesn't really say much about a company that makes it a better place to work than another company.
|
|
#
?
Aug 23, 2011 21:09
|
|
|
Otto Skorzeny posted:Few people who call themselves software engineers have any engineering background, schooling or experience, and for the most part any they do have is ad-hoc.
|
|
#
?
Aug 23, 2011 21:46
|
|
|
Orzo posted:Sources? This sounds like something you just made up. What other branches of engineering are in any way useful for a software "engineer" (domain specific knowledge notwithstanding)? http://en.wikipedia.org/wiki/List_of_engineering_branches Wikipedia calls software engineering a subset of computer engineering which is a subset of electrical engineering. If we don't accept that defintion, why would a software engineer have any reason to have engineering experience?
|
|
#
?
Aug 23, 2011 21:53
|
|
|
Maybe I'm being naive, but an engineer engineers solutions to problems, typically technical ones?  Regardless, take for example a software engineering course, you learn principles, skills and techniques that can be implemented in any language and cross domains (admittedly I'm generalising) - I don't see how that differs too much from other engineering disciplines?
|
|
#
?
Aug 23, 2011 22:08
|
|
|
The thing is, "Engineer" in a job title is a thing that usually comes with a certification from the NCEES and you get to be considered a certified PE (Professional Engineer). Like 95% of other job titles with Engineer in them have some sort of certification that they have to achieve. Software guys don't, and just kind of started attributing themselves the title of Engineers. The NCEES just recently started licensing Software Engineers, though I don't know how good this is or if it's useful or meaningful, it's just "something" right now.
|
|
#
?
Aug 23, 2011 22:15
|
|
|
No Safe Word posted:Like 95% of other job titles with Engineer in them have some sort of certification that they have to achieve. Cicero fucked around with this message at 22:24 on Aug 23, 2011 |
|
#
?
Aug 23, 2011 22:20
|
|
|
Similarly, my brother is a 'Drainage Engineer', and designs and fits drainage systems for residential/commercial/industrial customers - he isn't certificated, nor is it a requirement that he is.
|
|
#
?
Aug 23, 2011 22:41
|
|
|
From Wikipedia:quote:In Canada, it is considered illegal to practice engineering, or use the title 'Engineer', without a Professional engineers license. quote:In the United States... The title "Engineer" is legally protected in many states, meaning that it is unlawful to use it to offer engineering services to the public unless permission is specifically granted by that state, through a Professional Engineering license, an "industrial exemption", or certain other non-engineering titles such as "operating engineer". Employees of state or federal agencies may also call themselves engineers if that term appears in their official job title. The IEEE's formal position on this is as follows: "The title, Engineer, and its derivatives should be reserved for those individuals whose education and experience qualify them to practice in a manner that protects public safety. Strict use of the title serves the interest of both the IEEE-USA and the public by providing a recognized designation by which those qualified to practice engineering may be identified." It is generally a requirement in the United States to have at least a Bachelor of Science degree in an engineering discipline or related applied science to be considered an engineer and practice as such. Software engineers are (imo) no more "Engineers" than are "Audio Engineers"
|
|
#
?
Aug 24, 2011 00:05
|
|
|
My university (Waterloo) has a Software Engineering program, which is sort of a halfway between CS and Computer Engineering. It's still accredited by the PEO, so they get the rings and become P. Enges, but there's nothing stopping you from programming without any such credentials.
|
|
#
?
Aug 24, 2011 01:00
|
|
|
Otto Skorzeny posted:So we sort of ironically add process in search of rigor with no rigorous reason to add anything, to say the least of the particular things we are adding and end up removing real rigor if anything by doing so. Thank you for posting this. I was actually discussing a very similar problem with a co-worker last week. The amount of unsubstantiated inference masquerading as "best practice" in this industry is at times staggering to me, especially given that many of the people espousing these beliefs graduated with a supposedly "scientific" degree.
|
|
#
?
Aug 24, 2011 01:06
|
|
|
Dire Penguin posted:It probably varies too much by the company for this question to be worth much, but I'll ask anyway. For a first job, assuming two roughly equal positions, would I be better off looking at a small company or a large one? Yeah you're going to get a bunch of personal responses for this question. Here's my answer: It's best to be the second worst person on the team. You want to be able to learn from lots of people, but still have someone to teach new things to. It's probably much easier to do that working for a small company. Oh, how handy! I've arrived at my personal preference in a seemingly objective way.
|
|
#
?
Aug 24, 2011 01:11
|
|
|
Dransparency posted:Thank you for posting this. I was actually discussing a very similar problem with a co-worker last week. The amount of unsubstantiated inference masquerading as "best practice" in this industry is at times staggering to me, especially given that many of the people espousing these beliefs graduated with a supposedly "scientific" degree. Sorry, who here holds a scientific degree? Computer Science is very poorly named. The scientific method is not to be found, and computers (as opposed to 'computing' in general) are generally not wanted. I see the point you're making but "scientific" is the wrong word. Maybe "rigorous"?
|
|
#
?
Aug 24, 2011 01:13
|
|
|
pokeyman posted:Sorry, who here holds a scientific degree? Computer Science is very poorly named. The scientific method is not to be found, and computers (as opposed to 'computing' in general) are generally not wanted. Who here? No one, as far as I know, given your classification of CS (though I'm sure someone will pop out of the woodwork shortly to correct me). I have, however, worked with several people who held more traditional science degrees, and I was at least partially thinking of them with that statement. Perhaps my language was overly broad in that sense. Beyond that, I'm not yet sure I agree with your classification of CS as "not science." Pure computer science is most closely related to mathematics, which is frequently classified as a science (at least by the dictionary definition). Maybe you disagree with this assessment? I will agree that software engineering is not a science, but that doesn't mean the field couldn't benefit from greater application of the scientific method. The most obvious examples in my day-to-day work are the lack of proper experimental techniques surrounding performance testing and usability studies, which both lend themselves quite well to a scientific approach. Depending on whether you agree with the classification of mathematics as a science, techniques like formal verification of specifications/implementations could also fit here. Regardless of whether CS is a "real science," my original point was that I'd like to see more people making claims based on evidence, rather than at times shaky chains of inference.
|
|
#
?
Aug 24, 2011 02:17
|
|
|
Orzo posted:Sources? This sounds like something you just made up. It is ok; because even if they did have qualifications they would likely be worthless  anyway, I think if we called ourselves software engineers we would have to take responsibility for when software fails
|
|
#
?
Aug 24, 2011 02:36
|
|
|
Dransparency posted:Beyond that, I'm not yet sure I agree with your classification of CS as "not science." Pure computer science is most closely related to mathematics, which is frequently classified as a science (at least by the dictionary definition). Maybe you disagree with this assessment? After reading what you linked to, yes I am inclined to disagree. In the same way *pure* mathematics is distinguished from *applied* mathematics, there is a distinction within cs. *pure* computer science is *pure* mathematics, and more accurately a branch of philosophy; a discipline of thought. (i.e lambda calculus, type systems, proofs etc). Meanwhile science is more applicative; a rational method for evaluating your ideas and approach. (i.e analysis - evaluation, experiments, testing and hypothesis). The thing is, the reason we have 'software engineering' and 'computer science' is nothing to do with that. The reality is that the names came from how academia embraced computing. In some schools, computing came under the EE dept and so was named software engineering; in others computing came under the mathematics department and so was christened 'computer science'. So the distinction between 'cs' and 'se' varies wildly between universities. Really you have to look no further to understand the relative immaturity of computing as we have yet to establish a common vernacular - even words like 'strong typing' are continually redefined, so why would 'computer science' have a meaning?
|
|
#
?
Aug 24, 2011 02:55
|
|
|
tef posted:After reading what you linked to, yes I am inclined to disagree. In the same way *pure* mathematics is distinguished from *applied* mathematics, there is a distinction within cs. Hmm, so if I understand you correctly you actually have the opposite point of view? Namely, that applied CS is more "scientific" than pure CS? I certainly think aspects of CS fall under the "mathematical sciences" provision of the definition I linked. tef posted:The thing is, the reason we have 'software engineering' and 'computer science' is nothing to do with that. Eh, I still think there's utility in differentiating between the harder and softer sides of the field, and those terms seem as good as any to me. If you're telling me that the definitions aren't clear enough for unambiguous use, I guess I'll try to be more explicit when using them in the future.
|
|
#
?
Aug 24, 2011 03:21
|
|
|
tef posted:anyway, I think if we called ourselves software engineers we would have to take responsibility for when software fails Does getting fired count?
|
|
#
?
Aug 24, 2011 03:40
|
|
|
tef posted:In some schools, computing came under the EE dept and so was named software engineering I don't think this is the case; if it were, then software engineering programs would likely fall under the school of engineering at these places and involve core engineering classes, which they generally don't, and likely involve some sort of rigor rather than teaching religion as science, and maybe even have some faculty cross over. This would also imply that SE people would know basic linear algebra, how a modern computer works, etc. On another note, i would love if software engineering were a real thing. I'm not saying that we would all have to get our PE*, but if we could have a relationship with computer science** similar to that which mechanical engineering has with newtonian mechanics, or electrical engineering with ohm's and kirchoff's laws, or systems engineering has with control theory, or aeronautical engineering has with navier-stokes equations and other fluid dynamics, or nuclear engineering has with all sorts of loving physics, I think it would be a positive development, and one of great magnitude. There are a ton of systems developed today which demand high reliability and performance in which software is an integral and even driving component. We have some theory built up under several academic disciplines and developed in several industries which we can build on! It's a shame that we instead want to wallow in the stone age of our discipline. *After consulting some friends who are Verified Old Farts, it seems that a PE is meaningful in more or less every field, but has different weight in each. For example, in civil engineering it is required to do practically anything (often legally mandated), in mechanical engineering it's good for a lot of things, etc. I would expect given the weight it carries in civil engineering that it would be more common on the electrical power systems side of EE than on the microelectronics/IC side, and that in chemical engineering more weighty and common for dudes designing cracking towers and poo poo than folks designing bioreactors for pharma. **I am greatly discouraged by the fact that many of the folks carrying the software engineering banner seem to think that basic, fundamental CS knowledge isn't just unnecessary but useless. Would you want to drive in a car designed by MechE's that held a similar view of calculus or statics? The mind, it boggles!
|
|
#
?
Aug 24, 2011 03:42
|
|
|
tef posted:anyway, I think if we called ourselves software engineers we would have to take responsibility for when software fails I think I'd actually be willing to accept this, assuming:
|
|
#
?
Aug 24, 2011 04:41
|
|
|
tef posted:The thing is, the reason we have 'software engineering' and 'computer science' is nothing to do with that. It's also true that EE departments, engineering colleges, and mathematics departments all played a role in making computing into an academic discipline. A number of universities that were early computer adopters (I say most, but I don't have solid data) started off their computing departments as places that other faculty could bring their computational problems. These facilities ran the nascent commercial computers of the time, and individual faculty started hashing out computational theories or practices on their own. This sometimes led to the faculty-users coalescing into departments. Other times, EE departments were the locus of computer development, as the hardware to build computers was quite complex (see, for instance, the Moore School at Penn). And, finally, you're absolutely right that mathematics departments often became the home of computing research, as a lot of computing is very much mathematics, both applied and theoretical. Overall, I agree with you that computer research began quite fragmented. You can see this effect pretty starkly at, for instance, UIUC. They have a computer science program in the liberal arts college, officially as part of the mathematics department. They also have a computer science department in the college of engineering, which offers its own degrees. They also have a computer engineering program as part of what was originally the EE department, and is now ECE. FWIW, they offer a software engineering specialization as part of the engineering CS curriculum. What I don't agree with you about, however, is that this is where software engineering came from. I am almost positive that the term came into use because of the 1968 NATO Software Engineering Conference. To quote Robert McClure, one of the participants: quote:In the fall of 1968 and again the in fall of 1969, NATO hosted a conference devoted to the subject of software engineering. Although the term was not in general use at that time, its adoption for the titles of these conferences was deliberately provocative. As a result, the conferences played a major role in gaining general acceptance, perhaps even premature, for the term. The motivation for these conferences was that the computer industry at large was having a great deal of trouble in producing large and complex software systems. In essence, their vision of software engineering seems to be exactly what Otto Skorzeny desires. Rather than a bunch of engineers saying "we're engineers doing software, so it's software engineering" as could be inferred from your idea, the attendees of the NATO conference wanted to formalize the construction of software, using strong theoretical underpinnings. Of course, I believe Otto's complaints still ring true (as they did 15 years after the NATO conference when C.A.R. Hoare brought up the similar questions in "Programming: Sorcery or Science?"). Software engineering, on the whole, is poorly defined and often not practiced with any type of rigor. It often devolves into cargo cult management practices in an attempt to get the hottest new product to market faster, drat the consequences. One thing holding back the field may be the lax enforcement of standards. Consumers are hungrier for new features than they are for a product with the long tail of bugs significantly curtailed (see OpenBSD's popularity as an example of this), meaning there is little market desire for "real" software engineering. Safety critical systems (nuclear reactors, etc.) have the force of law behind some of their software engineering practices. Much like what Dransparency said, I wonder if setting down standards and putting punishments and indemnifications into law would help other fields. I haven't worked any fields where this has happened, though, so lord knows if it actually makes their code any better. Menacer fucked around with this message at 18:03 on Aug 24, 2011 |
|
#
?
Aug 24, 2011 08:48
|
|
Failed Sega Accessory Ahoy!
|
All this talk about software engineering is compelling me to post the talk Glenn Vanderburg did about the subject.
|
|
#
?
Aug 24, 2011 10:56
|
|
|
krisis posted:All this talk about software engineering is compelling me to post the talk Glenn Vanderburg did about the subject. This is a pretty interesting presentation, bit of a mini history lesson.
|
|
#
?
Aug 24, 2011 17:53
|
|
|
I'm a junior .NET programmer, I graduated recently but have previous VB.NET experience. I've been trying to find a .NET job all summer without any luck, either I don't have enough experience or I don't know the required technology (WFC, WPF, Reporting Services, etc.). I have 2 job offers right now, neither really .NET, but I have to work so I have to take one. But I can't decide which to pick. I'm not asking you guys to pick for me obviously, but I just wanted to know your thoughts. Here's the two companies side-by-side: Company A: downtown, 15 minutes away Company B: industrial area 1 hour away A: unimpressive B: slightly better A: Their main product is a Delphi application used to manage attorney practices (time management, billing, etc.) B: They develop an air traffic management system. Lots of intercommunicating embedded C++ devices, along with Windows software for operators. A: I'd be assisting with maintenance for their legacy Delphi program (I have no Delphi experience and will learn on the job), as well as POSSIBLY help write their new C#/WinForms version. B: At first I'd be writing either a C# (WinForms) or C++ (Qt) GUI, this will be decided later. After that, I'd assist the senior programmers with C++ programming. A: Did not give me a technical test B: Gave me a basic C++ test, nothing more A: No strings attached B: My ex-boss recommended me (he works there now), so out of etiquette I wouldn't be able to quit early on if it turns out I hate it. I'd have to stay there for at least a year, probably two. A: Seems like a really laid-back environment, I'd probably stand out with my work ethic B: They have no other juniors. They exclusively hire senior C++ programmers (which is weird since their technical test was so basic any CS graduate could pass it) and interns during the summer. I'll stand out with my lack of general experience and lack of C++ experience. If it weren't for the WinForms programs I wrote for my ex-boss they wouldn't look twice at me. Any comments?
|
|
#
?
Aug 24, 2011 19:49
|
|
|
Company B looks better in my opinion, since you won't have to deal with terrible legacy code and will be able to learn a lot from the seniors.
|
|
#
?
Aug 24, 2011 20:29
|
|
|
MachinTrucChose posted:Company A: downtown, 15 minutes away Which of the attributes you listed is important to you, and which aren't? For example, I would hate a two hour-long commute (though maybe if I was sitting the whole time with some kind of internet-able device... nah gently caress that) and would happily take the much closer job even if it sounded slightly worse in all other categories. Also, what's this "I have to stay two years if someone recommends me" crap? If it's not working it's not working, why would you waste everyone's time just because you had an in?
|
|
#
?
Aug 24, 2011 20:37
|
|
|
quote:
|
|
#
?
Aug 24, 2011 21:20
|
|
|
MachinTrucChose posted:A: Did not give me a technical test Oh my lord don't work for company A. But don't work for company B, either, if you're going to spend 2 hours commuting (unless it's by train). It will eat into your soul.
|
|
#
?
Aug 24, 2011 22:34
|
|
|
MachinTrucChose posted:Any comments? Unless you need the money I would keep looking. .NET isn't going away anytime soon, there will be something else, or bite the bullet and move somewhere that actually has demand for .NET programmers cause there has to be somewhere near you. If none of that is an option I would take the C++ job. Regardless know that one role is going to be maintaining a Delphi app, the other a C++ app. Career wise avoid the hell out of Delphi. I have met a few people along the way who are RPG programmers, a programming language first released in 1959 by IBM and a bunch of systems were developed. Some of those systems are still in use, maybe not from 1959 but ~a long time ago~. And those systems still need programmers to look after them. Now at first from the developers point of view it probably seemed like a decent position, good pay, stable company, why not? But then next thing you know you're 40 and have spent the last 10 years writing RPG and the company you work for was bought by some other company and they decided to can the RPG product line and so you're kinda thinking its time to move on but all you really have on your CV is RPG. You look on the job sites but noone is really hiring RPG programmers except ancient banks in foreign countries and your 40 now and don't really want to have to move but that is all you seem qualified to do based on experience so its kinda a hard choice between moving countries or driving a taxi or something. I'm not actually dramatising that I have met people in that exact situation. I would stay the hell away from a Delphi maintenance type role, or if you needed it for whatever reason I would keep it short 2 years max and have a very clear exit plan.
|
|
#
?
Aug 25, 2011 00:44
|
|
|
|
| # ? Apr 29, 2024 13:47 |
|
|
I've decided to go for the C++ company, thanks for the input everyone. I'm certainly going to move near a subway station on the same line as theirs to cut commute time. unixbeard: Thanks for the advice. About your first suggestion though, waiting for a .NET position is not an option, I've been looking all summer and only got a single .NET interview. Either my lack of experience or techs/frameworks/libraries like ASP.NET and WFC is making HR ignore me entirely. If I need to "level up" my .NET skills, I'll do that on my own time. If as I suspect it's the experience holding me back (I haven't programmed since 2009, doesn't look good on a resume), then I don't think it will matter to HR whether I've been doing C++ or .NET recently as long as I add .NET to my skills section.
|
|
#
?
Aug 25, 2011 03:57
|
|