Newbie Programming Interviews/Get a Job Megathread: Fake it 'til you make it

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Newbie Programming Interviews/Get a Job Megathread: Fake it 'til you make it

umbrage: Sep 5, 2007; beast mode

Jam2 posted:

This Fall I will be a college junior. So far, I've been admitted to the CS programs at Michigan and Illinois, but I've also applied to CMU, Stanford, and I'm on the wait-list at MIT.

Academically, I'm a strong student, but I'm totally new to the field of study. I've been around IT my whole life, but I just started programming a few months ago.

How do I make myself employable as a software engineer in two years? Can I be competitive straight out of undergrad with whizkid hackers who've already put in their 10,000 hours?

Well, lucky for you, most programmers can't program. Most of those kids are going to learn bad habits in the first 100 hours, cheat for the next 300 in school, and then repeat the same bullshit mistakes for the next 9,600+, making me spend all of my hours fixing their mistakes.

I actually have a pretty good partitioning function for whether or not you will do well as a software engineer. Read this.

Does this get you excited? Do you see how an algorithm, developed in 1956, is still relevant to some of the most important computational issues of the current day? Do you appreciate its elegance? Even if you can't put it in to words, or put it in code yet, can you conceptualize ways to improve it?

This is the sort of mindset you need to be an excellent software engineer. If you possess it, then you will do fine, and it will show. Whizkid hackers may have infinite basement time and infinite Mountain Dew, but if you can begin to cultivate a way to see the entire world as graphs, trees, queues, stacks, cliques, alphabets, and functions operating on all of them, you will never be out of a job.

Truly internalizing the fundamental concepts of CS will give you the toolset to evaluate, decompose, and attack just about any problem in the real world that involves the representation, transformation, and presentation of information. None of it is bullshit.

Otherwise, you know, start learning how to kiss rear end, write lovely code for three years that does every design anti-pattern in the book, and get thee to middle management ASAP.

# ¿ May 3, 2011 15:33

Adbot: ADBOT LOVES YOU

# ¿ May 3, 2024 13:33

umbrage: Sep 5, 2007; beast mode

Shitpost Gaze posted:

2banks1swap.avi, are you Flux_core? Because you act almost exactly like him.

For real though, I'd like to hear some stories about how some of the people in here got involved with their professors and research while they spent time as an undergrad. I'm at the point where I've got a handle on my classes and I'm thinking about this sort of thing. I'm interested to see how other people went about getting research and some of the things some of you all have done, maybe how research directly affected job prospects too.

You know, so that I can get a job when I graduate.

1) Take the course offered in your area of interest.
2) Go to the professor's office hours.
3) Ask relevant questions about the assigned coursework.
4) Tell said professor that because she or he has been such an inspiration in $CS_FIELD, you were hoping she/he has some independent work you could do.

The thing is, honestly the chances of a professor having actual research work that an undergrad could do is pretty low, because they want to work on novel things which, probabilistically, you can't handle yet. But you stand a decent chance of being in a support role, which means preparing coursework, or doing software grunt work in a team (e.g. building UIs or writing drivers) for a graduate student. The availability of this sort of work greatly depends on $CS_FIELD--more likely in Computer Vision or Robotics, less so in Theory of Computation.

Howaaaaayver, even doing this sort of work is Invaluable as gently caress, because you develop a personal rapport with a professor. Professors spend a lot of time chatting with other professors. You will become a Known Undergraduate in the department, which means

A) you are vouched for when you want to work for another professor, and
B) you are not going to want/need money.

Because professors usually have neither time nor money to waste.

If you provide more specific fields of interest, I could perhaps give more specific advice. But if you want to find opportunities that translate to a leg up on a professional career, you want to find a professor who is working on things with applicability to the real world. Stuff like automated cars, advanced database engines, image and voice recognition.

# ¿ May 3, 2011 15:59

umbrage: Sep 5, 2007; beast mode

If I'm hiring someone, I'm going to be looking at how well they can integrate into the established workflow and programming culture, no matter how lovely it is, over whether they know the latest and greatest. LINQ is neat, but it's for a very specific mindset and fairly specific problem domains. If you just came in on your first day and started throwing it around in a shared codebase, that's time commited to

Have to explain to every other developer what LINQ is
Have to wait on them to learn it
Have to explain it to them again
Have to debug their mistakes when they attempt to update your code
Have to debug their misinterpretations when they attempt to refactor your code to something they can understand without spending their evenings reading Essential LINQ

I mean, clearly the shop you interviewed with is not good, at all, and you should refuse an offer, but don't let that excuse the possibility that your attitude about using LINQ was poor.

It comes across as, "When all I have is a hammer, everything looks like a skull," and the shop's dysfunction is a bit of a strawman. You are eventually going to find a shop where the coders are good, but just don't have the time/desire/need to learn LINQ, and then you just look like a uni-tasker who can't adapt. You should have a lot of tools in your toolkit, from basic concepts up to modern API knowledge. This was the time to show deep knowledge of basic concepts.

Did the job posting even mention LINQ as a required or even desired skill?

# ¿ May 27, 2011 15:30

umbrage: Sep 5, 2007; beast mode

gariig posted:

I think using LINQ for data manipulation (reversing a string) is a correct way to answer the question.

It is the correct solution. But I don't think it's the correct way to answer a technical interview question. Don't get me wrong: I heart LINQ. I heart .NET. It is the way I would do it in production code, too. But 99% of the time, you're not supposed to just use Foundation classes/JDK/&c.

It never hurts to mention that there's something that's already available, because that alone can prove you are up to speed with the latest technology/practices. But reversing strings isn't supposed to be a rote knowledge challenge. It's an algorithm runtime and space requirements challenge.

gariig posted:

What if the interviewer asked to see him sort a list of integers? Should he make a class and inherit from CollectionBase since generics are used for "a very specific mindset and fairly specific problem domains" of having typed collections?

I think you ask if you can use Generics. If it's too Magic Bullet for the problem, the interviewer won't allow it, or will say, "That would be smart, but let's try it without that." But again, production solutions != interview solutions.

gariig posted:

After three and a half years (.NET 3.5 was release 11/2007) I think using LINQ to answer a question is valid. The interviewer asking him not to use LINQ is also valid as a follow up.

In a good and just world, yes. And yet, he said

Ithaqua posted:

I had to explain what LINQ was to the interviewer, which led to an explanation of extension methods, which led to him asking me to do it again, the "normal" way.

So clearly some people still haven't gotten the memo.

# ¿ May 27, 2011 18:23

umbrage: Sep 5, 2007; beast mode

take boat posted:

But will LINQ really flabbergast a team of professional .NET programmers in 2011? If a team is ignoring a part of their platform that can greatly simplify their code, and it takes a newbie to introduce it, well good on the newbie.

Good professional programmers? No. But it flabbergasted the interviewer.

I wasn't wrapped up in something particular about LINQ. LINQ, Rails, Matlab, whatever--there's almost always going to be a shortcut/existing solution. But the useful answer, for an interviewer, for a coding question is almost never going to be

:smug:

"BOOM ONE LINER COUNT IT SUCKA"

My original post was talking to two points:
1) Clever coding fucks with crappier colleagues
1a) Clever is a low bar for some companies.

2) Magic bullet answers aren't generally useful in interviews.

# ¿ May 27, 2011 18:41

Adbot: ADBOT LOVES YOU

# ¿ May 3, 2024 13:33

umbrage: Sep 5, 2007; beast mode

Ithaqua posted:

I wouldn't want to work somewhere where clever was a low bar. My goal is to be the second dumbest person on the team.

That's funny--I've always said I wanted to be the dumbest person, but you make a good, subtle point.

Paolomania posted:

That is what he means by "clever is a low bar". Clever is just the minimum standard.

I meant "clever" to be as cute as one can get before the rest of the group can't refactor your code reliably. For some places that would be an enormous APL function for calculating the Chinese GDP. For others, it's a recursive call. I've had co-workers change a private constructor back to public because they didn't know how singletons worked.

# ¿ May 27, 2011 21:15

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Newbie Programming Interviews/Get a Job Megathread: Fake it 'til you make it