Tag Info

Hot answers tagged

119

I've got some bad news for you bhamlin: You aren't an intern. Rather, you are an unpaid/cheap employee. An internship is a unpaid or low-paid position where you can practice your newly aquired skills in a safe, (usually) relaxed environment, and get a chance to observe 'real' professionals in your field doing 'real' work, while getting feedback on the ...


99

My first open source contribution was for a library that I had previously used (and would've suffered greatly without) on a previous paid project. During my initial use I had spotted a bug in the code so I created a patch, joined the project, and submitted it for review. About 8 months later when I had some free time I decided that I would give back (and ...


85

Companies that value their developers and their products know that sustainability is important. 60 hour weeks are not sustainable. Developers are not manual laborers, they are decision makers. Our decision making faculties become depleted and require rest far more quickly than our bodies. This will have adverse effects on the developers (like causing them to ...


52

There are several things you can and should do to prepare for the task: Think about the problem and draw some diagrams. Make sure that you know what the problem is that you are trying to solve. Do research on what you are trying to do. The internet is a valuable source of information. I am not saying ask Stack Overflow -- I am saying do research on how ...


42

Ask about what tech blogs they read, ask what the applicant finds interesting in current tech and why. Essentially, for a phone interview you want to figure out if this is someone who is enthusiastic about technology and programming and is interested in learning and knowing more. Since this is a junior, you can't expect that they know many advanced topics, ...


41

There are too many things you can't learn in college. There are also many things that are specific to the company. In both cases, you have a choice: either you ask your colleagues for explanation, or you don't ask anything to anybody, and take the risk to make a mistake. If I hire someone who doesn't have a professional experience, I would not mind if ...


35

Give him the chance to shine I've actually had a very similar position for some time but now I think I'm making some progress with the developer. I think in the end it will only be a case of commit shyness but I just told him "I need you to commit and push to the server so I can help you better if you get stuck, and you can help me better to oversee the ...


34

Sounds like a scam, not a job. Nigerian job offer? heh. I have never worked at, nor know anyone who has worked at a place that would require something of the likes of that in the field of software development in over 12 years of experience from startups to gov't to edu to fortune top 20. Keep looking - it will only get worse.


33

Do some people have a knack for programming. Absolutely. If you don't have a knack for it, can you still be a great programmer? Yes, but it'll take more practice. Either way, being really good at programming takes time. It's sort of like playing an instrument. Are some people naturally gifted? Yep. But many of the greats just practiced longer, and ...


33

It pretty much boils down to don't guess. Mostly new programmers do it, but I've seen veterans do it too, because they think it saves research time. Something doesn't work, so you add a +1 or a -1, change a true to a false or vice versa, reorder some statements, add or change delays, change thread priorities, and other small transformations, basically ...


32

Disclaimer : you may want to check with you manager and/or your Human Ressources Department before following my advice. Plain and simple : Fire him from your team. He does not have the basic skills needed to be a programmer. Your company is certainly not a programming school, and you cannot be a full time team leader and a school teacher at the same time. ...


32

Many people won't like this idea, but I am advocating this wherever I can: regardless of the programming language and environment, if they don't have any experience and if there are maintenance tasks which come up from real world bug reports of customers of yours, try to make sure they get assigned to that kind of task at least for 30-40% (+) of their time. ...


28

IMO, the most prominent points that speak for Python as an entry-level language are these: it has a shallow learning curve - going from nothing to "Hello world" is much faster than in most other languages it is intuitive - the syntax was designed to follow the principle of least surprise, and it is very consistent overall (unfortunately, the standard ...


27

Am I too aggressive about the changes which i am proposing ? Without specifics (what new techs you're proposing, why they're rejecting them, where they feel that DRY is impractical and why, etc), it's hard to evaluate the amount of merit to your proposals and that's important for your aggressiveness. If you want them to use a new framework because you ...


26

Here what I suggest to do in order to find your perfect match: If you have an open-source project that you already use, know and care about, it should be your first candidate to try. Otherwise think about what you would like to do in general and search for a project in this area. When you have found a potential project, do not rush into it. Try to use it ...


26

Absolutely not. Will it help? Of course. Is it required? No. With your experience you shouldn't have too much of a problem getting a junior level position. As with all things, your potential employers need to know that you can get the job done. You may need to show them some of the work you've done (maybe an open source contribution? or something ...


25

I disagree. First, scripting languages are at a higher level of abstraction, and there is nothing wrong with this. At the beginning one is just trying to learn the principles. Actually I would say that choosing a lower level language may encourage bad coding, since one has to deal with some details before being able to understand them. Instead with a simpler ...


25

If he liked the product you built, but is stuck up on your use of Backbone, you both need to have a conversation about the desired tech stack. As developers, we ought to use tools that are readily available, and consequently, smoothly move our flow of work. If he expected you to build the front-end from scratch, he should have been explicit and had good ...


24

There is a gap. The gap boils down to two factors: certainty and size. The professor knows what he wants. The client does not know what he wants. This is often your biggest headache. The professor knows you can do it. In the real world nobody knows if it can be done. YOu have to work with the client to constrain the task to be feasible. The school task is ...


24

There is no perfect solution, but some things that might help: Break tasks down into the smallest possible units -- break them down until you have things you can do. Restate the immediate task or problem at hand to make sure you really understand it. Then do some analysis and repeat. Pick the simplest task first, even if it seems too simple. Ask for help ...


24

As a CS major you have problem solving skills at your disposal. It's unclear what type of projects they want to develop. If I had to guess they probably want you to help automate some of the internal processes. I'd start by trying to get a big picture diagram of what processes are currently in place and the dependencies between departments for each of these ...


23

Not knowing what version control is, or how to use it properly. One of the junior developers who has been at my company for several months recently had to get taught the very very basics of Subversion. It really made me cringe... she's been checking in code to live projects the whole time... and had no idea what she was doing...?


23

Not asking enough questions I know they're juniors, I expect that they will make mistakes and just not know things. So many royal f**k ups could have been avoided by just asking a question instead of assuming something. Honestly, I can't be pestered enough. I had TONNES of questions when I started out - asking them saved my arse on a number of occasions. ...


22

You don't have to think ahead, merely be very clear on what was done, and be very clear on what you are doing right now. Subroutines should say what they do, do what they say, and not have hidden dependencies. Then someone calling them can more easily reason about what they will do. Avoid global state. (Variables, singletons, etc.) The more state that ...


21

I take an open-ended approach to phone interviews, but to put some structure on it I usually ask the person to talk through the resume that they submitted. Often, the way they go through their resume will prompt other questions and you'll get a better understanding of what they are like. The other thing to think about during the phone interview is to ask: ...


21

There is (much) more to Software Development than cranking out code. Mentoring Project Leading Software Design This leads to: Responsibility A Junior Developer is still learning the language and frameworks on a daily basis, and thus should be focusing on this. A mentor (or experienced colleagues at least) is expected to guide him, especially the design ...


20

It doesn't matter where you start. It matters where you go after you start. BASIC may not be the most elegant language on the planet, but it encompasses the fundamentals of procedural programming, and that's enough to get started. I started with BASIC. I didn't stay there.


20

Anywhere from 0 to 5 or 7 (or so). Arguments for the low side: Not everyone is set out to be a mentor. I have worked with some developers who were so gruff that they would have scared someone into a new career. If you expect the senior devs to maintain the same level of output, then keep the number low. Arguments for a higher amount: Some devs ...


20

Pair Programming sounds like a great possibility here. Give four of them two of the simpler of these bugs, let them pair up and have each pair tackle one of them. Phrase this request as, "Can you figure out what's causing this?". Don't get them to start thinking about how to fix it yet. Once they do have some level of an explanation, then ask them how it ...



Only top voted, non community-wiki answers of a minimum length are eligible