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

«‹›728 »

evensevenone: May 12, 2001; Glass is a solid.

In some states at least, your employer can get a (pretty big) discount on insurance for doing pre-employment drug screens.

# ? Oct 29, 2013 02:56

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 22:02

hedgecore: May 2, 2004

Protip, as I've been interviewing candidates for front-end developer positions:

If you repeatedly use an acronym (like MVC) but it doesn't seem like you know what it means, I'm going to ask you what the three letters stand for and a simple description of the role they play. If you're going to ramble for several minutes, (wildly guessing incorrectly, at that), I'm going to have a bad time.

Everyone handles these interviews differently, but if anyone has specific questions about front-end dev interviews, feel free to ask.

# ? Oct 29, 2013 03:23

SplitDestiny: Sep 25, 2004

It's pretty rare to find a dev on the west coast who hasn't smoked pot...

# ? Oct 29, 2013 03:39

oRenj9: Aug 3, 2004; Who loves oRenj soda?!?; College Slice

Deus Rex posted:

I mentioned the obvious potential for XSS in that foreach loop right away, but the interviewers hinted that there were other problems. Unfortunately I suffer from severe migraines due to an injury sustained in the Merchant Marines which make it hard to focus, and - fearing a drug test - I didn't smoke my usual "medical" in the morning. Is there something I missed in this code, or was I imagining things?

I actually don't see the XSS that you're talking about here, care to enlighten me?

I have the following issues with that code:

pre:
```
displayBoughtLeadsTable()
```
There is no information being passed into the function, that means that database connections and such are basically magical.
pre:
```
$leads = Lead::getBoughtLeadsForUser();
```
Get the bought leads for what user (more magic)? There's no explicit error handling or checking the results or anything of that nature.
pre:
```
$html = ...;
```
It's 2013, use loving templates already.
pre:
```
foreach ($leads as $lead) {
```
Again with the not bothering to check that $leads is an array of some appropriate object.
None of those fields have defaults defined for the null case.

# ? Oct 29, 2013 04:30

Che Delilas: Nov 23, 2009; FREE TIBET WEED

HondaCivet posted:

... one of "the best answers he's ever heard" to one of his questions and "made his day."

You can't say something like that and not tell us what the question and answer were. :colbert:

# ? Oct 29, 2013 05:56

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

SplitDestiny posted:

It's pretty rare to find a dev on the west coast who hasn't smoked pot...

It's me.

# ? Oct 29, 2013 07:13

HondaCivet: Oct 16, 2005; And then it falls
And then I fall
And then I know

Che Delilas posted:

You can't say something like that and not tell us what the question and answer were.

This probably won't be that interesting or helpful but I'll post it anyway . . . He asked what technologies I was most excited about using during the next stage of my career. I said in so many words that I was excited to use whatever worked best for the problem at hand because all (worthwhile) technologies have their strengths and weaknesses. That's honestly how I feel but I could tell that it was kind of a "trick" question because I already knew a bit about the culture of the company and the stuff they do. YMMV on using that kind of answer elsewhere, I feel like most places would take it as me being wishy-washy or something so I almost didn't even say it.

SplitDestiny posted:

It's pretty rare to find a dev on the west coast who hasn't smoked pot...

As soon as I get a new job that doesn't loving drug test . . .

HondaCivet fucked around with this message at 07:26 on Oct 29, 2013

# ? Oct 29, 2013 07:24

No Safe Word: Feb 26, 2005

SplitDestiny posted:

It's pretty rare to find a dev on the west coast who hasn't smoked pot...

Well there's a difference between "has smoked pot" and "can't put a hold on it long enough to pass a drug screen", though drug screens are weak in general for screening anything but entry-level positions in my opinion.

# ? Oct 29, 2013 09:01

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

Deus Rex posted:

code:

...
                    <th>Purchase Date</th>
                    <th>Date</th>
                    <th>Description</th>
                    <th>Zipcode</th>
                    <th>Name</th>
                    <th>Phone Number</th>
                    <th>E-Mail</th>
		    <th>Bought</th>
...
        $html .= '<td>' . $lead->getBuyDate() . '</td>';
        $html .= '<td>' . $lead->getDate() . '</td>';
        $html .= '<td>' . $lead->getDescription() . '</td>';
        $html .= '<td>' . $lead->getZipcode() . '</td>';
        $html .= '<td>' . $lead->getName() . '</td>';
        $html .= '<td>' . $lead->getPhone() . '</td>';
        $html .= '<td>' . $lead->getEmail() . '</td>';
        $html .= '<td>' . $lead->getBought() . '</td>';

I'm not a webdev but this not being in an array that's split off from the rest of the logic just makes me cry.

Also why is it getBoughtLeadsForUser? Shouldn't it be getUser (or have that passed in, really!) and then call getBoughtLeads with the user passed in? Too much global magic.

I don't see why you can infer there's XSS risk here.

# ? Oct 29, 2013 09:54

shrughes: Oct 11, 2008; (call/cc call/cc)

Skuto posted:

I don't see why you can infer there's XSS risk here.

It's concatenating unprocessed user-supplied strings into HTML.

Edit II: Sorry, I'll let Sondie post.

shrughes fucked around with this message at 10:30 on Oct 29, 2013

# ? Oct 29, 2013 10:20

Safe and Secure!: Jun 14, 2008; OFFICIAL SA THREAD RUINER
SPRING 2013

How do we know that getBoughtLeadsForUser() doesn't do any processing before returning its leads?

# ? Oct 29, 2013 10:30

SplitDestiny: Sep 25, 2004

No Safe Word posted:

Well there's a difference between "has smoked pot" and "can't put a hold on it long enough to pass a drug screen", though drug screens are weak in general for screening anything but entry-level positions in my opinion.

You don't need to 'hold it together' because that company is letting you know that it has a terrible culture and that you need to avoid it. No one needs to subject themselves to a drug test in this job market.

# ? Oct 29, 2013 10:36

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

Safe and Secure! posted:

How do we know that getBoughtLeadsForUser() doesn't do any processing before returning its leads?

That was my thinking too. For all we know it's retrieved from a database and has been sanitized already or was never user-supplied. You just can't infer that from this code.

# ? Oct 29, 2013 10:36

shrughes: Oct 11, 2008; (call/cc call/cc)

Because that would be dumb.

Yes you can infer it, making XSS mistakes is one thing but doing crazy pre-transformation of strings far up the API would be a losethosian level of crazy.

# ? Oct 29, 2013 10:36

SplitDestiny: Sep 25, 2004

Skuto posted:

I don't see why you can infer there's XSS risk here.

Obviously the user input text was already stored html escaped in the database.

# ? Oct 29, 2013 10:37

Safe and Secure!: Jun 14, 2008; OFFICIAL SA THREAD RUINER
SPRING 2013

Yeah, I guess it could be considered dumb to have functions that pass around user-supplied data sanitize their values. It would make more sense to just sanitize once when you print user-supplied data than sanitize it every time it's accessed. But that would give you another opportunity to tell your interviewer "hey, this code is dumb because [x]". :colbert:

# ? Oct 29, 2013 10:41

SplitDestiny: Sep 25, 2004

oRenj9 posted:

[*]
pre:
foreach ($leads as $lead) {
Again with the not bothering to check that $leads is an array of some appropriate object.

Note, you should never do this in real life.

# ? Oct 29, 2013 10:43

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

Maybe it's just inexperience in this field but neutering potentially dangerous input before going off and storing it somewhere where it's used for god-knows-what by god-knows-who sounds like proper defensive programming to me.

For all I know the user is Bobby Tables and some intern next summer won't have heard about stored procedures before coding up some internal app that's not supposed to be exposed to the internet.

However the point is taken: being defensive means not assuming that the sanitation happened, so it should be pointed out for the original code.

# ? Oct 29, 2013 10:44

shrughes: Oct 11, 2008; (call/cc call/cc)

Safe and Secure! posted:

Yeah, I guess it could be considered dumb to have functions that pass around user-supplied data sanitize their values. It would make more sense to just sanitize once when you print user-supplied data than sanitize it every time it's accessed. But that would give you another opportunity to tell your interviewer "hey, this code is dumb because [x]".

I have no idea what you're saying. But yes, it would be terrible to have an arbitrary contour line in your project separating API layers of unescaped vs. escaped strings instead of a clear and simple one, if that's what you're saying.

# ? Oct 29, 2013 10:45

b0lt: Apr 29, 2005

Skuto posted:

Maybe it's just inexperience in this field but neutering potentially dangerous input before going off and storing it somewhere where it's used for god-knows-what by god-knows-who sounds like proper defensive programming to me.

For all I know the user is Bobby Tables and some intern next summer won't have heard about stored procedures before coding up some internal app that's not supposed to be exposed to the internet.

However the point is taken: being defensive means not assuming that the sanitation happened, so it should be pointed out for the original code.

I\\\\'m sure you\\\\'ve never seen anything like this before!

# ? Oct 29, 2013 10:47

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

shrughes posted:

I have no idea what you're saying. But yes, it would be terrible to have an arbitrary contour line in your project separating API layers of unescaped vs. escaped strings instead of a clear and simple one, if that's what you're saying.

Nobody said it had to be arbitrary. My thinking was that it could happen on input, not output.

But after thinking about it more, the problem of doing it on input rather than at the point where it's used is that at the input point you can't properly anticipate what could be dangerous for the use point. Do you need to check for SQL like statements, or HTML XSS stuff? No way to know, so you need to check at the point of use [*].

That certainly explains a bit why errors like this are so common even at places where you'd think they know about it.

[*] Or you have places like Adobe where they just try to cover every possible case on the input side and end up telling you that you have an "illegal name" when you enter your real name.

This was insightful!

Hiowf fucked around with this message at 11:01 on Oct 29, 2013

# ? Oct 29, 2013 10:51

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

SplitDestiny posted:

You don't need to 'hold it together' because that company is letting you know that it has a terrible culture and that you need to avoid it. No one needs to subject themselves to a drug test in this job market.

If you want to work on cool poo poo (weapons, spacecraft, etc) rather than WEBDEV 2: SQL INJECTION BOOGALOO, this is false.

# ? Oct 29, 2013 13:08

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

Otto Skorzeny posted:

If you want to work on cool poo poo (weapons, spacecraft, etc) rather than WEBDEV 2: SQL INJECTION BOOGALOO, this is false.

You probably forgot to add "in the US".

# ? Oct 29, 2013 13:49

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Skuto posted:

You probably forgot to add "in the US".

In the context of the fields we are talking about, this goes without saying. Cf:

Nb. the space graph is as a percentage of GDP rather than in absolute dollars; adjusting to absolute or PPP dollars makes the difference significantly larger, as the US has the largest GDP.

# ? Oct 29, 2013 13:57

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

Otto Skorzeny posted:

Nb. the space graph is as a percentage of GDP rather than in absolute dollars; adjusting to absolute or PPP dollars makes the difference significantly larger, as the US has the largest GDP.

Doesn't really matter for the percentage-wise amount of people in the country working on it, and spending is only somewhat correlated with production.

If you look at export (rather than spending), you'll find that some relatively smaller countries export a ton of stuff, which means that a relatively large part of the population works on it.

It's not hard to find a job working on weapons or satellites where I live (and you won't need to pass a drugs check), and part of the design work is then produced under license in the US. Considering that, your post to me reads like someone from Foxconn saying "If you want to work on the next iPhone, China is the only option!". I'm slightly exaggerating here, but you get the point: there is absolutely a weapons and space industry outside the USA.

# ? Oct 29, 2013 14:28

Steve French: Sep 8, 2003

Do any of you know if space x drug screens? It would not surprise me at all if they don't, and I'd much rather work there than somewhere like Lockheed Martin (and not for any reasons related to drugs)

# ? Oct 29, 2013 14:54

Sarcophallus: Jun 12, 2011; by Lowtax

Steve French posted:

Do any of you know if space x drug screens? It would not surprise me at all if they don't, and I'd much rather work there than somewhere like Lockheed Martin (and not for any reasons related to drugs)

Then why does it make any difference?

# ? Oct 29, 2013 15:07

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Steve French posted:

Do any of you know if space x drug screens? It would not surprise me at all if they don't, and I'd much rather work there than somewhere like Lockheed Martin (and not for any reasons related to drugs)

I have two friends who work at Vandenberg, and one of them works for SpaceX. She drug screened, but she's a rocket engineer rather than a programmer.

# ? Oct 29, 2013 15:12

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Skuto posted:

I'm slightly exaggerating here, but you get the point: there is absolutely a weapons and space industry outside the USA.

Well all right then.

https://www.youtube.com/watch?v=-3mCvCDBoTQ

# ? Oct 29, 2013 15:14

Steve French: Sep 8, 2003

Sarcophallus posted:

Then why does it make any difference?

It makes a difference because one person said that anywhere worth working drug tests, and another person said that if you want to work on space poo poo, you're going to have to be drug tested. That's why.

# ? Oct 29, 2013 16:08

oRenj9: Aug 3, 2004; Who loves oRenj soda?!?; College Slice

SplitDestiny posted:

Note, you should never do this in real life.

I disagree, it is good practice to always check that the results from a function match your expectation when said function is presenting data from a secondary datasource. If you test for issues programmatically, then you can log when they happen, catch them early and have more information about why it happened. If just assume that a section of code will never break, then you'll only ever discover there is a problem with somebody happens to see, "PHP Fatal error: Call to a member function getBuyDate() on a non-object."

The addition of a few lines of code, in this instance, can really save a lot of development effort by helping to catch issues early.

# ? Oct 29, 2013 19:27

Pollyanna: Mar 5, 2005; Milk's on them.

Otto Skorzeny posted:

If you want to work on cool poo poo (weapons, spacecraft, etc) rather than WEBDEV 2: SQL INJECTION BOOGALOO, this is false.

You mean "if you want to work on government/defense stuff", in which case loving duh they're going to drug test.

Also not everyone wants to make robots to blow brown people up. There's plenty of dev positions that don't involve the government.

# ? Oct 29, 2013 20:03

Good Will Hrunting: Oct 8, 2012; I changed my mind.
I'm not sorry.

I'm really interested in the work being done at a local place that does contract stuff for government projects. I recall reading some bad things about government contracts somewhere though. I don't remember if it was here or not.

Any advice?

# ? Oct 29, 2013 20:14

Steve French: Sep 8, 2003

oRenj9 posted:

I disagree, it is good practice to always check that the results from a function match your expectation when said function is presenting data from a secondary datasource. If you test for issues programmatically, then you can log when they happen, catch them early and have more information about why it happened. If just assume that a section of code will never break, then you'll only ever discover there is a problem with somebody happens to see, "PHP Fatal error: Call to a member function getBuyDate() on a non-object."

The addition of a few lines of code, in this instance, can really save a lot of development effort by helping to catch issues early.

More lines of PHP is never the right solution.

# ? Oct 29, 2013 21:27

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

Steve French posted:

More lines of PHP is never the right solution.

Let me tell you about being a consultant...

# ? Oct 29, 2013 21:33

NovemberMike: Dec 28, 2008

oRenj9 posted:

I disagree, it is good practice to always check that the results from a function match your expectation when said function is presenting data from a secondary datasource. If you test for issues programmatically, then you can log when they happen, catch them early and have more information about why it happened. If just assume that a section of code will never break, then you'll only ever discover there is a problem with somebody happens to see, "PHP Fatal error: Call to a member function getBuyDate() on a non-object."

The addition of a few lines of code, in this instance, can really save a lot of development effort by helping to catch issues early.

How does this help you if something bad is passed in? Just make sure that everything fails gracefully and log errors when they happen, that'll do a lot more for you than trying to ensure that every variable that's passed in is set correctly. Trying to preemptively solve problems can be comforting but it can mean spending a lot of time trying to fix things that aren't problems.

# ? Oct 30, 2013 03:21

oRenj9: Aug 3, 2004; Who loves oRenj soda?!?; College Slice

NovemberMike posted:

How does this help you if something bad is passed in? Just make sure that everything fails gracefully and log errors when they happen,

That's exactly what I'm suggesting.

# ? Oct 30, 2013 17:26

Bhaal: Jul 13, 2001; I ain't going down alone; Dr. Infant, MD

Deus Rex posted:

I just got back from an interview at a web dev shop. It seems like a really awesome opportunity and I sure hope I get it ! Anyway, there was one hitch in the interview; they asked me to review some problematic PHP code and I'm not sure I caught everything:

For me it boils down to one thing, the sample code is giving us clues that the entire project is one giant goddamned nightmare. They obviously have some sort of framework. There's some global/static Lead object, and presumably some global/static "current logged in user" information that it has access to, and db access is being handled by something else upstream. These are at least assumptions I'm making, if they were fishing for answers like "it's not passing a userid" or "how do we know we're connected to a database?" I'd cry foul that blurs the lines between what should be assumed and what shouldn't because we can only guess at the behavior we're not seeing in the example. If that's the case, how do we know we've authenticated the user being logged in? Etc. Anyway, none of these things about them having some sort of framework is particularly terrible (though I'd rename that function getBoughtLeadsForLoggedInUser() or something, and it would just curry the current logged in user to a more generic function), in fact it's a slightly hopeful sign compared to that of "absolutely no framework".

But then we get to the rub, this framework apparently has no concept of code and presentation layers, not to mention something like templates/partials/etc. Also, our function appears to exist outside a class hierarchy or even MVC hierarchy but that might be the example stripping away too much. In either case I'd respond to them that the most problematic part of that php code is the large mess it suggests the rest of the codebase to be in. If this is some sort of application/platform that has php and html braided together like this all over the place, unless I'm being brought in with the specific goal to refactor/rewrite their backend I would probably take a pass at the opportunity. I'd only say yes to dev and maintenance of a codebase like that and keeping it more or less as it is if I were in a desperate / need the money type situation, and on day 1 I'd start my campaign to rewrite it anyway.

As for XSS I would take the tack that since the leads are coming out of the database, the washing should take place before it goes into the database. So to me that's not an issue to be concerned with as I would assume we can trust what's coming out of our own DB, and if it were a concern we're back to problemo numero uno that the entire project is one giant goddamned nightmare.

Bhaal fucked around with this message at 21:19 on Oct 31, 2013

# ? Oct 31, 2013 21:14

etcetera08: Sep 11, 2008

Deus Rex, I think maybe you should get into embedded programming. Your mind is in the right place for it, not this web dev bullshit. Plus, fewer drug screens because they know their applicants aren't renowned potheads like web developers.

# ? Nov 1, 2013 00:26

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 22:02

Rescue Toaster: Mar 13, 2003

Embedded is the best.

Rescue Toaster fucked around with this message at 20:01 on Sep 14, 2017

# ? Nov 1, 2013 02:46

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

«‹›728 »