it's really sad if someone claims to be a developer, but isn't, gets past the phone interview and makes it to the in-person interview. That's why I'm anti-FizzBuzz. You should be good enough that you don't let someone who would fail a FizzBuzz even walk into your office. Making someone who passed your phone filter take a quiz is insulting. If you ask me to do that shit I'll show you my New York finger.
I was mostly referring to phone screens. I haven't had an in-person interview with someone who wasn't at least decent at coding.
Wow, how do you give someone that kind of technical quiz over the phone? Usually just have discussions with people, and it becomes pretty easy to judge whether they know what they are talking about without asking some kind of formal technical question.
One thing I should also clarify is that the contents of an interview is going to vary greatly depending on the level we are hiring for. For someone who is entry level, we may not do any code during a phone screen and just do really basic stuff during the in-person. For someone who is senior level, we also won't do code because we care more about their design and architecture skills. Most of the interviews I do are for people at my level, the coders who do most of the work. We screen them up front because we care about two things: Is their code clean? Is their code comprehensible? Mid-level coders who can't do those two simple things are not worth interviewing further because they are an immediate risk to the longevity of our codebase, regardless of other skills.
You would be surprised at how many developers with 5-20 years of experience cannot pass this simple test.
It's strange I see this divide in the class already where only 5-10% of the kids understand exactly what is going on and enjoying the coding bits while 90% are scraping by. Then there are the super outliers like the people who have luckily been introduced to coding since primary school and currently are already able to get developer positions in small firms or do projects for companies like Humble Bundle.
I'm trying to work out how the majority graduate into a paying job. Well I do know of one, I have a friend who is a product manager / consultant guy at Oracle who acts as a 2 way parser between the client and the developer. He's not stupid he just says he wouldn't be able to code most anything if I asked him yet he comfortably makes well over $100k.
I'm just gonna leave this here, and say I should really move over to Qt from Tkinter. Also I made this like last week or something; it might be useful for disappointing DMs
I'm just gonna leave this here, and say I should really move over to Qt from Tkinter. Also I made this like last week or something; it might be useful for disappointing DMs
Here's a real puzzler. I've got a remote server running nginx -> gunicorn -> django. If an exception is thrown in a view, instead of the 500 server error page being returned, it hangs for ~10 seconds and I get 502 bad gateway. No exceptions are logged anywhere. I've got logging cranked down to DEBUG. Views that don't throw an exception render normally.
Running it locally, everything works. I immediately see the 500 server error page. Same settings.py in both places.
Figured it out. Firewall wasn't letting emails out. Django sends emails when DEBUG is false. Shouldn't the firewall explicitly block the connection rather than letting it wait and wait until it times out?
Figured it out. Firewall wasn't letting emails out. Django sends emails when DEBUG is false. Shouldn't the firewall explicitly block the connection rather than letting it wait and wait until it times out?
That's what happens. You send a TCP SYN. Your SYN never made it past the firewall. Your connection times out waiting for the ACK that was never even sent.
I would create a inner class for each Listener if they are fairly simple and only used in one class. It's a good compromise between using anonymous inner classes and splitting every Listener out into its own file.
public class OuterClass { private AnObject someAttribute; private AnotherObject someOtherAttribute;
public static void setup() { someAttribute.addListener(new InnerClassListener()); }
private class InnerClassListener implements SomeListener { @Override public void onEvent(Event e) { someOtherAttribute.doSomething(e.getProperty()); } } }
Not sure if this is what was meant by "I'm thinking of making classes for each of the listeners and doing new ()" or not, but that's how I'd do it.
ostlerdev [6:47 PM] like you could have a Listeners class that contains all the listener methods
[6:47] but having a single class for 8 lines doesnt feel efficient
I have to disagree with this; the number of separate classes and the number of lines of code in a class are pretty much entirely irrelevant metrics.
The key criterion for distinguishing whether or not something should be a separate class is code reuse: if you expect to have another use for it except for within the one class you're using it, then it should be an external class. Otherwise, it probably shouldn't be, unless perhaps it's so big that having it in a separate file improves readability.
Also, having it be part of an inner class as opposed to an external class makes it much easier for you to give it access to the data of the outer class. In your example, you would need to do extra work to give external classes access to mPositionValue and mSocket.
From what I see of your posted code, you do want an inner class; the only question is whether to make it an anonymous inner class or a named inner class, i.e. (to extend Snickety-Snake's example) you're down to the difference between this: public class OuterClass { private AnObject someAttribute; private AnotherObject someOtherAttribute;
private class InnerClassListener implements SomeListener { @Override public void onEvent(Event e) { someOtherAttribute.doSomething(e.getProperty()); } }
public void setup() { someAttribute.addListener(new InnerClassListener()); } }
and this: public class OuterClass { private AnObject someAttribute; private AnotherObject someOtherAttribute;
private SomeListener innerClassListener = new SomeListener() { @Override public void onEvent(Event e) { someOtherAttribute.doSomething(e.getProperty()); } }
public void setup() { someAttribute.addListener(innerClassListener); } }
The only difference between the two is that the first lets you potentially create multiple instances of that listener, while the second does not. Thus, if you would never expect to make multiple instances of that same listener within the context of OuterClass, you may as well use the second approach; otherwise, you should use the first.
Comments
One thing I should also clarify is that the contents of an interview is going to vary greatly depending on the level we are hiring for. For someone who is entry level, we may not do any code during a phone screen and just do really basic stuff during the in-person. For someone who is senior level, we also won't do code because we care more about their design and architecture skills. Most of the interviews I do are for people at my level, the coders who do most of the work. We screen them up front because we care about two things: Is their code clean? Is their code comprehensible? Mid-level coders who can't do those two simple things are not worth interviewing further because they are an immediate risk to the longevity of our codebase, regardless of other skills.
You would be surprised at how many developers with 5-20 years of experience cannot pass this simple test.
I'm trying to work out how the majority graduate into a paying job. Well I do know of one, I have a friend who is a product manager / consultant guy at Oracle who acts as a 2 way parser between the client and the developer. He's not stupid he just says he wouldn't be able to code most anything if I asked him yet he comfortably makes well over $100k.
I also started a Patreon
Also I made this like last week or something; it might be useful for disappointing DMs
https://github.com/TommyHanusa/BadCharacterGenerator/releases
... do you read API documentation too?
500 server errorpage being returned, it hangs for ~10 seconds and I get502 bad gateway. No exceptions are logged anywhere. I've got logging cranked down to DEBUG. Views that don't throw an exception render normally.Running it locally, everything works. I immediately see the 500 server error page. Same settings.py in both places.
What could this possibly be?
Many people will set up drop/nolog rules for anything that might cause a performance problem.
sajattack [6:42 PM]
yeah but for instance this
[6:42]
mForwardImageButton.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
double percent = mPositionValue / 10000.0;
Log.i("percent", String.valueOf(percent));
mSocket.emit("forward", percent);
}
});
[6:42]
probably bad
ostlerdev [6:42 PM]
yeah
[6:42]
maybe set a variable to contain the onclick
[6:43]
then link it that way?
sajattack [6:43 PM]
yeah
ostlerdev [6:43 PM]
that is generally how I would do it
sajattack [6:43 PM]
or maybe
new ForwardImageButtonListener()
ostlerdev [6:43 PM]
eh maybe, but I would say like
sajattack [6:43 PM]
and then separate all that shit out
ostlerdev [6:45 PM]
private Object forwardListener = new View.OnClickListener() {
@Override
public void onClick(View v) {
double percent = mPositionValue / 10000.0;
Log.i("percent", String.valueOf(percent));
mSocket.emit("forward", percent);
}
}
mForwardImageButton.setOnClickListener(forwardListener);
[6:45]
I know that object shit is wrong, but you get the gist
[6:45]
that way you have cleaner gui code
sajattack [6:45 PM]
oh interesting
ostlerdev [6:45 PM]
like how you wouldnt put a ton of js logic inline in html
[6:45]
right?
sajattack [6:45 PM]
that's almost the same though
ostlerdev [6:46 PM]
yeah but then you can have like
sajattack [6:46 PM]
I'm thinking of making classes for each of the listeners and doing new ()
ostlerdev [6:46 PM]
mForwardImageButton.setOnClickListener(forwardListener);
mBackImageButton.setOnClickListener(backListener);
mLeftImageButton.setOnClickListener(leftListener);
mRightImageButton.setOnClickListener(rightListener);
sajattack [6:46 PM]
so there's less clutter
ostlerdev [6:46 PM]
ehhh
[6:46]
classes should be ~200 lines imo
[6:46]
I wouldnt suggest a new class for each listener
[6:47]
unless there is a shit ton of logic in there
sajattack [6:47 PM]
yeah I'm not sure
ostlerdev [6:47 PM]
like you could have a Listeners class that contains all the listener methods
[6:47]
but having a single class for 8 lines doesnt feel efficient
sajattack [6:47 PM]
yeah
public class OuterClass {
private AnObject someAttribute;
private AnotherObject someOtherAttribute;
public static void setup() {
someAttribute.addListener(new InnerClassListener());
}
private class InnerClassListener implements SomeListener {
@Override
public void onEvent(Event e) {
someOtherAttribute.doSomething(e.getProperty());
}
}
}
Not sure if this is what was meant by "I'm thinking of making classes for each of the listeners and doing new ()" or not, but that's how I'd do it.
The key criterion for distinguishing whether or not something should be a separate class is code reuse: if you expect to have another use for it except for within the one class you're using it, then it should be an external class. Otherwise, it probably shouldn't be, unless perhaps it's so big that having it in a separate file improves readability.
Also, having it be part of an inner class as opposed to an external class makes it much easier for you to give it access to the data of the outer class. In your example, you would need to do extra work to give external classes access to
mPositionValueandmSocket.From what I see of your posted code, you do want an inner class; the only question is whether to make it an anonymous inner class or a named inner class, i.e. (to extend Snickety-Snake's example) you're down to the difference between this:
public class OuterClass {
private AnObject someAttribute;
private AnotherObject someOtherAttribute;
private class InnerClassListener implements SomeListener {
@Override
public void onEvent(Event e) {
someOtherAttribute.doSomething(e.getProperty());
}
}
public void setup() {
someAttribute.addListener(new InnerClassListener());
}
}
and this:
public class OuterClass {
private AnObject someAttribute;
private AnotherObject someOtherAttribute;
private SomeListener innerClassListener = new SomeListener() {
@Override
public void onEvent(Event e) {
someOtherAttribute.doSomething(e.getProperty());
}
}
public void setup() {
someAttribute.addListener(innerClassListener);
}
}
The only difference between the two is that the first lets you potentially create multiple instances of that listener, while the second does not. Thus, if you would never expect to make multiple instances of that same listener within the context of
OuterClass, you may as well use the second approach; otherwise, you should use the first.